firmware install problem

General discussions and questions abound development of code with MicroPython that is not hardware specific.
Target audience: MicroPython Users.
nagylzs
Posts: 40
Joined: Sat Jan 19, 2019 8:01 pm

firmware install problem

Post by nagylzs » Sat Jan 25, 2020 7:59 am

Hi! I have two boards: an ESP32 development board and another board that contains an ESP32 module. The former was bought as-is, the other is custom made. If I download esp32-idf3-20191220-v1.12.bin from http://micropython.org/download then I can burn it to both devices, and they both work. If I compile a new custom firmare myself (with an extra module added under esp32.LEDControl) then the development board works with it (including the custom module), but the other one is not. It does not even boot up.

Here is an image of the module on the devboard:

https://imgur.com/a/Gam13nY

And this is the custom board:

https://imgur.com/a/WA4C1LT

I think they are exactly the same type.

Can you think of anything that might cause a problem like this? How is it possible that one firmware works with both, and the other just works with one of them?

User avatar
MostlyHarmless
Posts: 166
Joined: Thu Nov 21, 2019 6:25 pm
Location: Pennsylvania, USA

Re: firmware install problem

Post by MostlyHarmless » Sat Jan 25, 2020 8:51 am

Hard to tell without more details about that extra module and how the two boards differ in wiring. Just speculating, but could it be that the extra module is mucking with GPIO(s) that are connected to vital things on the "custom board"?


Regards, Jan

nagylzs
Posts: 40
Joined: Sat Jan 19, 2019 8:01 pm

Re: firmware install problem

Post by nagylzs » Sat Jan 25, 2020 12:26 pm

I was careful about not connecting the reserved pins on my custom board. But even if the wiring was wrong, this wouldn't explain why it works with one firmware and not with the other.

I can post the schematic of the whole board here, but I'm not sure if it will help.

nagylzs
Posts: 40
Joined: Sat Jan 19, 2019 8:01 pm

Re: firmware install problem

Post by nagylzs » Sat Jan 25, 2020 12:40 pm

Here is the whole schematic. Some LED shunt resistor values are too high, but otherwise it is how it is. The pin header called "limiter" has a jumper. When input is <=12V then pins 2 and 3 are shorted with a jumper. In this case the 7812 is not used, only the AMS1117. When input > 12V then pins 1 and 2 are shorted. In that case AMS1117 is powered from the 7812. The SV1 pin header is just there to break out extra GPIO pins, but it is not actually used for anything. The pin header named PROG is used to re-flash the firmware.

https://imgur.com/a/h5K2Fuy

User avatar
MostlyHarmless
Posts: 166
Joined: Thu Nov 21, 2019 6:25 pm
Location: Pennsylvania, USA

Re: firmware install problem

Post by MostlyHarmless » Sat Jan 25, 2020 2:45 pm

Right, nothing obvious in that schematic that could explain the problem.

Have you tried to compile the firmware (tag v1.12 checked out) without any extra modules?


Jan

User avatar
tve
Posts: 216
Joined: Wed Jan 01, 2020 10:12 pm
Location: Santa Barbara, CA
Contact:

Re: firmware install problem

Post by tve » Sun Jan 26, 2020 12:13 am

ESP-WROOM-32 modules can have varying flash sizes as well as varying flash chips that have differing capabilities, such as dio vs qio and 40Mhz vs 80Mhz. Your flashing of the firmware may not have gotten the right modes. The other issues are that a handful of gpio pins need to be pulled up or down at boot time ("strapping") and the board may differ in how that is handled.
Finally, to get help, post the output of the serial port as you flash and then boot!

nagylzs
Posts: 40
Joined: Sat Jan 19, 2019 8:01 pm

Re: firmware install problem

Post by nagylzs » Sun Jan 26, 2020 10:18 am

> ESP-WROOM-32 modules can have varying flash sizes as well as varying flash chips that have differing capabilities, such as dio vs qio and 40Mhz vs 80Mhz. Your flashing of the firmware may not have gotten the right modes.

Yes, but please note that the 1.12 firmware that can be downloaded from micropython.org can be flashed to both devices and they both work. But the other firmware that I compile from source code, only works on one of them. Using the same flash mode in all 4 cases.

I'm 100% sure that the flash size is identical, because I can query the available free space (with the good firmware). The ESP chips look identical to me.

Anyway, I just checked out the v.12 tag and recompiled the firmware from scratch, without any custom modules added. Here is the log of the flashing for the factory produced devboard

Code: Select all


Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.
Building with ESP IDF v3
Erasing flash
esptool.py v2.8-dev
Serial port /dev/ttyUSB0
Connecting........_____....._____....._
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: cc:50:e3:8c:db:7c
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Erasing flash (this may take a while)...
Chip erase completed successfully in 9.4s
Hard resetting via RTS pin...
Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.
Building with ESP IDF v3
Writing build-GENERIC/firmware.bin to the board
esptool.py v2.8-dev
Serial port /dev/ttyUSB0
Connecting.....
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: cc:50:e3:8c:db:7c
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB
Compressed 1241840 bytes to 783468...
Wrote 1241840 bytes (783468 compressed) at 0x00001000 in 18.2 seconds (effective 545.9 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...


And here is the log of flashing the custom board:

Code: Select all


╰─$ ./burn.sh 
Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.
Building with ESP IDF v3
Erasing flash
esptool.py v2.8-dev
Serial port /dev/ttyUSB0
Connecting....
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: a4:cf:12:74:bf:80
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Erasing flash (this may take a while)...
Chip erase completed successfully in 8.7s
Hard resetting via RTS pin...
Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.
Building with ESP IDF v3
Writing build-GENERIC/firmware.bin to the board
esptool.py v2.8-dev
Serial port /dev/ttyUSB0
Connecting.......
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: a4:cf:12:74:bf:80
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB
Compressed 1241840 bytes to 783468...
Wrote 1241840 bytes (783468 compressed) at 0x00001000 in 18.5 seconds (effective 535.8 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...



> The other issues are that a handful of gpio pins need to be pulled up or down at boot time ("strapping") and the board may differ in how that is handled.

I'm aware of that. I have posted the full schematic, feel free to check if there is anything wrong with it. If there is something wrong, then it still does not explain why the board works with one firmware and not the other.

> Finally, to get help, post the output of the serial port as you flash and then boot!

My build tools are under linux. If I try to connect to the custom board with putty under linux, then I do not see any message, except for one strange graphical character. Even when I press the reset button on the board, nothing comes out of the serial line. But it may be a thing with putty and the linux terminal. I know that some special charater sequences can make putty work incorrectly. I remember that I was seeing some messages on Windows. I'm going to reboot to Windows and post messages from Windows/realterm shortly.
Last edited by nagylzs on Sun Jan 26, 2020 10:24 am, edited 1 time in total.

nagylzs
Posts: 40
Joined: Sat Jan 19, 2019 8:01 pm

Re: firmware install problem

Post by nagylzs » Sun Jan 26, 2020 10:23 am

Okay, so this is what I see on Windows, from RealTerm:

https://imgur.com/a/qHJauMh

I doubt that it will help though. :-( This seems to be a random pattern. I get a different set of (seemingly) random garbage every time I press the reset button. I have tried with different baud rates (115200 57600 38400 19200) but it is always the same.

User avatar
tve
Posts: 216
Joined: Wed Jan 01, 2020 10:12 pm
Location: Santa Barbara, CA
Contact:

Re: firmware install problem

Post by tve » Mon Jan 27, 2020 5:12 am

So your dev board doesn't have the typical "cross-over" FETs between RTS/DTR and io0/en, instead these are wired directly to your prog connector (check just about any commercial board, e.g. huzzah, nodemcu). The prog connector looks like a typical FTDI connector with power removed? How are you driving that? I like to use miniterm.py because I can toggle the DTR/RTS lines manually (ctrl-t ctrl-d and ctrl-t ctrl-r) or by passing --rts 0 --dtr 0 commandline options. Depending on how you have wired serial you may not be letting your esp32 boot...
Also, I see no "strapping" resistors, e.g. on io12, io15, io2, io5. These could have any value if they're floating and could work on a good day and break on a bad one. Please refer to section 2.4 "Strapping Pins" of the esp32 datasheet. Your hardware design needs some serious updates...

nagylzs
Posts: 40
Joined: Sat Jan 19, 2019 8:01 pm

Re: firmware install problem

Post by nagylzs » Mon Jan 27, 2020 3:57 pm

tve wrote:
Mon Jan 27, 2020 5:12 am
So your dev board doesn't have the typical "cross-over" FETs between RTS/DTR and io0/en, instead these are wired directly to your prog connector (check just about any commercial board, e.g. huzzah, nodemcu). The prog connector looks like a typical FTDI connector with power removed?
Yes. GPIO0 connects to DTR. RST connects to RTS, TX to RX and RX to TX. The fifth pin is GND. I have used this for many custom boards and it has always worked for me.
tve wrote:
Mon Jan 27, 2020 5:12 am
How are you driving that? I like to use miniterm.py because I can toggle the DTR/RTS lines manually (ctrl-t ctrl-d and ctrl-t ctrl-r) or by passing --rts 0 --dtr 0 commandline options.
For flashing, I use esptool. For accessing REPL, I use putty under linux and realterm under Windows. With realterm, it is possible to control DTR/RTS lines by toggling checkboxes on the interface. (In other words, I can reset the board with a mouse click, while the port is already opened.) I can see that the reset line works, because when I turn on and off RTS, then new garbage appears in the terminal.
tve wrote:
Mon Jan 27, 2020 5:12 am
Depending on how you have wired serial you may not be letting your esp32 boot...
Also, I see no "strapping" resistors, e.g. on io12, io15, io2, io5. These could have any value if they're floating and could work on a good day and break on a bad one. Please refer to section 2.4 "Strapping Pins" of the esp32 datasheet. Your hardware design needs some serious updates...
Okay, I'm going to read that again. BTW I have read that part before I designed my board, but it appeared to me that these pins have good pull up / pull down resistors by default. Unfortunately, IO2 and IO5 are not breaked out, but I might be able to solder resistors on them.

It is still a question: why it (always!) works with the stock firmware, and never with the one that I compiled. I guess it cannot be explained with bad wiring.

Post Reply