Bootloop with TTGO LoRa32 V2.1.6 board with platform-espressif32 v4.30 and higher #45
Labels
workaround
Workaround needed
Comments
|
Thanks for your workaround - i have the same board and get the same issue with latest espressif32. |
|
I tried to reproduce the issue with both the TTGO LoRa32 V2.0 and TTGO T-Beam V0.5 boards and both worked fine, without showing the issue. I only have the V2.0 of this board and none of the V2.1.x versions. For the test I upgraded all platforms and libraries ( This initiated install of the Espressif32 v4.3.0 platform. Below output for the TTGO LoRa32 V2.0 while using Espressif32 v4.3.0: BuildUploadRunningSo is this bootloop issue with Espressif32 v4.3.0 specifically related to the TTGO LoRa32 V2.1.6 board or could there be other reasons that caused the issue for you? By the way, Espressif32 v5.0.0 is already available. Are you still experiencing the same bootloop issue with v5.0.0? |
|
thank you for your time and investigation. |
|
To not alter the environment to much i just upgraded within PlatformIo The base of this test is still the main banch from 26th May. Build Upload Running (looping) I can conclude the bootloop situation persists. |
Thanks. To start, providing logging as shown above for each of the tested configurations will be useful. When exactly does the bootloop occur? Based on @hekopath's log above the upload appears to succeed after which the device is automatically reset and then right at the first run the boot loop starts. Is that correct? |
Do you mean LMIC-node's latest commit from 2022-04-30? |
|
Regarding:
The following is remarkable: Above build log shows How come your build log shows |
|
Which operating system and version are you using? |
|
Also keep an eye on the used esptool and elf2bin versions. The newer version (4.x) does call elf2bin with parameters to append an SHA checksum of the binary. The 4.x version of esptool does check for this, but if the bin was made including the SHA and esptool doesn't check for it, it may corrupt the bin while flashing. |
|
Thanks. So to my understanding: After updating the ESP32 platform version in PlatformIO it will be best to delete the |
|
And also make sure esptool is not mentioned with a specific (different) version in the requirements.txt for the Python virtual env. |
|
<deleted> |
Yes! |
Yes! |
W10 Pro 21H2 |
|
I tried another build. This time i further cleaned up by deleting .pio and .vscode folder. Used platformio.ini is the following: Build Upload Running (looping) |
|
As an addition: Build, Upload and Running |
|
Observations so far:
Next steps to further investigate the bootloop issue could be to:
I won't have time to dive further into this issue any soon. Also, not owning a TTGO LoRa32 V2.1.6 myself makes it difficult/impossible tot test and reproduce the issue. |
|
Do you have any of the other supported ESP32 based LoRa boards that you could test with Espressif32 platform v4.3.0(+)? Have you tried to upload standard Arduino sketches (e.g. blink) with PlatformIO to your board to see if the issue persists or not? That way you can check if the issue is more general or only occurs with LMIC(-node). |
|
Check the board definitions to see what's different. |
I have now tested it with a ttgo-lora32-v1 without any issues.
Furthermore i tried to flash cyberman54/ESP32-Paxcounter with a similar list of supported boards and can confirm the same behavior as with LMIC-node . ttgo-lora32-v1 build, upload and running without loop So i can confirm that it is not a LMIC-node specific problem. At least it is usefull to raise this issue and provide a workaround as @damanti-me did. |
Good to have this clear now. 🙂 It will still be good to know if possibly LMIC library related or not.
You're welcome. Others have ran (and will run) into this issue too, so it's good there is a workaround available. I will leave this issue open for now so others can more easily find it. |
lnlp
changed the title
lnlp
changed the title
|
As already described by @hekopath a workaround for the bootloop issue for the TTGO LoRa32 V2.1.6 board can be implemented as follows: This workaround causes Espressif32 platform v4.2.0 to be used for this board (only) instead of any of the newer versions that will cause the issue. Workaround:In file [env:ttgo_lora32_v21]
; TTGO LoRa32 v2.1.6 (ESP32).
; Onboard OLED display SSD1306 0.96" 128x64.
platform = espressif32with [env:ttgo_lora32_v21]
; TTGO LoRa32 v2.1.6 (ESP32).
; Onboard OLED display SSD1306 0.96" 128x64.
platform = [email protected]Once the issue gets fixed in a newer version of the Espressif32 platform, above workaround should be undone again. |
|
I had the same Issue with my TTGO LoRa32 V2.1.6 board. I was able to "fix" the bootloop by changing the value in to I can't really explain why it works, but my colleague, who suggested the fix, said something along the lines of cheaper OLED Displays dont connect the reset Pin, which causes these kinds of Problems. |
|
GPIO-16 and -17 might also be connected to SPI flash or PSRAM. |
|
I had the same issue on a cheap "LILYGO TTGO" branded board. |
|
This is related to what TD-er said. Merely calling |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Update: See further below for a more complete description of the workaround.
I have observed a bootloop after using the latest espressif32 plattform with a ttgo_lora32_v21 board.
My personal workaround was to specify the previous version in the env section for my board variant.
[env:ttgo_lora32_v21]
platform = [email protected]
Can anybody confirm this problem?
Tested with the current main branch (v.1.3.0 version fail to build because of #41 )
The text was updated successfully, but these errors were encountered: