Re: initial gpio state: power on -> boot -> rtos -> app.
On Sat, Feb 18, 2023 at 11:48 PM Tomek CEDRO wrote: > Hello world :-) > > I am working on a pretty industrial automation project right now that > will control 3 phase motor over 400V/25A relays. > > There are 6 relays to provide all possible modes of 3 phase motor > control. There are 3 groups of two relays for a task like direction > change, star-left-star-right, and star-triangle switch. Each two of > the relays in the group will have exclusive control (i.e. when one is > on the other will have control cut off). But there groups are not > fully exclusive physically due to their function. So when all three > groups are turned on then big bang happens :-) > > I am still wondering how to protect against this big bang. For sure I > will add some physical protection so this situation is impossible > (i.e. some sort of logic between GPIO and relays where only one line > will indicate possible safe operation state of all relays, while zero > or more than one line set high will always result in a safe state). > > This lead me to think of the initial state of the ESP32 GPIO pins > after boot then after NuttX starts.. or when device will be in > bootloader / flashing state.. in case of malfunction.. or malicious > actions (it might be connected to the internet somehow).. or simply > sending 0x to /dev/gpio0 etc etc? > > My question is: it is possible to be sure of the GPIO pin state since > power-on through bootloader + RTOS up to the application run? For > instance not to let all pins go high/low/random? > > Any hints welcome :-) > Tomek > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > Rather than use the default GPIO driver, I would probably consider a custom driver that doesn't present to applications as individual GPIO pins, but rather as higher level constructs (motor off, star-left, star-right, etc), with mappings to specific GPIO pins in board.h. That custom driver would initialize the actual pins to the safe state (motor off) on boot, would return the pins to that state when the driver is closed, and would produce only allowed combinations of GPIO outputs. In addition, never trust software when it could cause real-world big bangs! Since industrial controls must be connected to a safety controller (emergency stop or "E Stop"), that can put the entire machine or line in a safe state, I would design logic on the circuit board that E-stops the system if: (1) any forbidden combination of GPIOs is ever output, or (2) a hardware watchdog that ensures the software hasn't frozen. Cheers Nathan
Re: esp32 / pcnt / rotary encoder
Yes, you can use MCUBoot to do FOTA that is already is integrated on NuttX for ESP32 On 2/19/23, Tomek CEDRO wrote: > Allright, I have NuttX origin/master built on FreeBSD and running on > ESP32-DevKitC :-) > > For some reason uname -a shows release 10.4.0 not 12.0.0(99/dev whatever) > o_O > > The whole NuttX firmware build and flashing is faster than scripts > upload in MicroPython heheh.. and they fight for encoder / timer / > pcnt api for over two years.. I can also see CAN support.. maybe its > finally time to switch to NuttX for gd =) =) =) > > Now lets get to qencoder stuff ]:-> > > TANK U FOLKS! :-) > > Tomek > > ps/2: Does NuttX have some sort of FOTA mechanism so the signed > firmware could be updated remotely over WiFi/IP from some sort of > server with a fallback mechanism of > boot-from-last-that-worked-or-bare-nonalterable? :-) > > > % /usr/bin/time -h gmake -j10 all flash ESPTOOL_PORT=/dev/cuaU0 > > CPP: > /XXX/nuttxworkspace.git/nuttx/boards/xtensa/esp32/esp32-devkitc/../common/scripts/esp32_rom.ld-> > /zraid/daCPP: > /XXX/nuttxworkspace.git/nuttx/boards/xtensa/esp32/esp32-devkitc/../common/scripts/flat_memory.ld-> > /zraid/CPP: > /XXX/nuttxworkspace.git/nuttx/boards/xtensa/esp32/esp32-devkitc/../common/scripts/legacy_sections.ld-> > /zrLD: nuttx > CP: nuttx.hex > MKIMAGE: ESP32 binary > esptool.py -c esp32 elf2image -fs 4MB -fm dio -ff 40m -o nuttx.bin nuttx > esptool.py v4.4 > Creating esp32 image... > Merged 1 ELF section > Successfully created esp32 image. > Generated: nuttx.bin (ESP32 compatible) > esptool.py -c esp32 -p /dev/cuaU0 -b 921600 write_flash -fs detect > -fm dio -ff 40m 0x1 nuttx.bin > esptool.py v4.4 > Serial port /dev/cuaU0 > Connecting > Chip is ESP32-D0WDQ6 (revision v1.0) > Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, > Coding Scheme None > Crystal is 40MHz > MAC: 08:3a:f2:ab:ff:34 > Uploading stub... > Running stub... > Stub running... > Changing baud rate to 921600 > Changed. > Configuring flash size... > Auto-detected Flash size: 4MB > Flash will be erased from 0x0001 to 0x0003afff... > Compressed 172624 bytes to 97312... > Wrote 172624 bytes (97312 compressed) at 0x0001 in 1.9 seconds > (effective 742.0 kbit/s)... > Hash of data verified. > > Leaving... > Hard resetting via RTS pin... > 16,89s real 47,78s user 25,60s sys > > > % pyserial-miniterm /dev/cuaU0 115200 > --- Miniterm on /dev/cuaU0 115200,8,N,1 --- > --- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H --- > > nsh> ␛[Kuname -a > NuttX 10.4.0 74790c8033 Feb 19 2023 05:06:25 xtensa esp32-devkitc > nsh> ␛[Kcoremark > 2K performance run parameters for coremark. > CoreMark Size: 666 > Total ticks : 17470 > Total time (secs): 17.47 > Iterations/Sec : 686.891815 > Iterations : 12000 > Compiler version : GCC8.4.0 > Compiler flags : Using NuttX compilation options > Parallel PThreads : 2 > Memory location : Defined by the NuttX configuration > seedcrc : 0xe9f5 > [0]crclist : 0xe714 > [1]crclist : 0xe714 > [0]crcmatrix : 0x1fd7 > [1]crcmatrix : 0x1fd7 > [0]crcstate : 0x8e3a > [1]crcstate : 0x8e3a > [0]crcfinal : 0xa14c > [1]crcfinal : 0xa14c > Correct operation validated. See README.md for run and reporting rules. > CoreMark 1.0 : 686.891815 / GCC8.4.0 Using NuttX compilation options / > Defined by the NuttX configuration / 2:PThreads > > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >
Re: initial gpio state: power on -> boot -> rtos -> app.
Not to forget to consider the time between reset and first init. Default pin state mostly is input floating, or input weak pull-up. Don't let big bang happen that early. -- Ingenieurbüro-Filgis USt-IdNr.: DE305343278 -- sent by mobile phone Nathan Hartman schrieb am So., 19. Feb. 2023, 13:13: > On Sat, Feb 18, 2023 at 11:48 PM Tomek CEDRO wrote: > > > Hello world :-) > > > > I am working on a pretty industrial automation project right now that > > will control 3 phase motor over 400V/25A relays. > > > > There are 6 relays to provide all possible modes of 3 phase motor > > control. There are 3 groups of two relays for a task like direction > > change, star-left-star-right, and star-triangle switch. Each two of > > the relays in the group will have exclusive control (i.e. when one is > > on the other will have control cut off). But there groups are not > > fully exclusive physically due to their function. So when all three > > groups are turned on then big bang happens :-) > > > > I am still wondering how to protect against this big bang. For sure I > > will add some physical protection so this situation is impossible > > (i.e. some sort of logic between GPIO and relays where only one line > > will indicate possible safe operation state of all relays, while zero > > or more than one line set high will always result in a safe state). > > > > This lead me to think of the initial state of the ESP32 GPIO pins > > after boot then after NuttX starts.. or when device will be in > > bootloader / flashing state.. in case of malfunction.. or malicious > > actions (it might be connected to the internet somehow).. or simply > > sending 0x to /dev/gpio0 etc etc? > > > > My question is: it is possible to be sure of the GPIO pin state since > > power-on through bootloader + RTOS up to the application run? For > > instance not to let all pins go high/low/random? > > > > Any hints welcome :-) > > Tomek > > > > -- > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > > > Rather than use the default GPIO driver, I would probably consider a custom > driver that doesn't present to applications as individual GPIO pins, but > rather as higher level constructs (motor off, star-left, star-right, etc), > with mappings to specific GPIO pins in board.h. That custom driver would > initialize the actual pins to the safe state (motor off) on boot, would > return the pins to that state when the driver is closed, and would produce > only allowed combinations of GPIO outputs. > > In addition, never trust software when it could cause real-world big bangs! > Since industrial controls must be connected to a safety controller > (emergency stop or "E Stop"), that can put the entire machine or line in a > safe state, I would design logic on the circuit board that E-stops the > system if: (1) any forbidden combination of GPIOs is ever output, or (2) a > hardware watchdog that ensures the software hasn't frozen. > > Cheers > Nathan >
