Heltec Lora32 is not really the same as ttgo lora32 #17
Comments
|
cc @BCAnderson |
|
I have to apologize but I think building this is beyond my capabilities. looks like I'm no help there, but I'd be happy to try whatever you like on my board. |
|
no worries. I'll work on this tonight/tomorrow. |
|
Hi @BCAnderson, Can you try running the following three commands on your board (using the binary file I'm attaching)? This will allow me to test my theory. After running these commands, power cycle the board and see if it boots? Note: the two files you flash have different starting addresses You should use the correct file for your region though... |
|
Hi, Just let me know if you want me to run the same thing on my TTGO Lora32 which is the one that can run the Heltec build. |
|
Nice, that worked on my TTGO LoRa boards that came in today. Was otherwise going into a crash loop with: |
|
"> Nice, that worked on my TTGO LoRa boards that came in today. Was otherwise going into a crash loop with:" My TTGO LoRa board is stuck in the same (or similar) crash loop. What did you do?? |
|
I just ran the three commands above with the bin that is attached. |
|
I did this: "ets Jun 8 2016 00:22:57 rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) Backtrace: 0x40153634:0x3ffbbdc0 0x400e5bbb:0x3ffbbde0 0x400e82ee:0x3ffbbe10 0x400913c9:0x3ffbbe30 Rebooting..." So no change for me. :( |
|
@BCAnderson later today I'll push out a 0.1.7 build that takes advantage of a new stacktrace feature girts added. If you try running that load and give back the stacktrace in this bug we might be able to remote debug your board from here. |
based on initial encouraging feedback from @illperipherals if more people report success, we'll need to change the install instructions to: esptool.py --port COM10 --baud 921600 erase_flash esptool.py --port COM10 --baud 921600 write_flash 0x1000 system-info.bin esptool.py --port COM10 --baud 921600 write_flash 0x10000 firmware-HELTEC-US-0.1.6.bin
|
Howdy, I tried 1.7 And I got this: ets Jun 8 2016 00:22:57 rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) Backtrace: 0x55445400:0x3ffbbf20 0x400e5ba5:0x3ffbbf40 0x400e6757:0x3ffbbf60 0x400e8e8a:0x3ffbbf90 0x400913c9:0x3ffbbfb0 Rebooting... It's a different boot error but it still continually reboots. |
|
@BCAnderson you shouldn't need to run that tool, because I grabbed the image here for you to use. Alas, I think I'll need to come back to this tomorrow because (as unlikely as it sounds) I think I might actually be slightly coronamotized - and I'm going to go lay down. |
|
Howdy Kevin ets Jun 8 2016 00:22:57 rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) Backtrace: 0x400ff646:0x3ffbc080 0x400e601d:0x3ffbc0a0 0x400e6bcf:0x3ffbc0c0 0x400e9302:0x3ffbc0f0 0x400913c9:0x3ffbc110 Rebooting... |
|
@BCAnderson okay - I'm back from a six day flu/covid break. I'll check this stack trace and comment later today. |
|
@BCAnderson sorry to ask this, but can I ask you to try this one more time with 0.1.9 and send in the stack trace? I would do it myself, but I don't have a board from your mfg. for some reason, just using the git tags is not allowing me to generate a build that makes sense for that stack trace. For instance, for that trace I get: So I'm now doing what I should have done all along, I'm including the elf file (which contains symbols with all builds, so in the future we can always generate the correct stack trace: |
|
installer script item moved to #27 |
|
Welcome back Kevin No change with 0.1.9 ets Jun 8 2016 00:22:57 rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) Backtrace: 0x400ff756:0x3ffbc080 0x400e612d:0x3ffbc0a0 0x400e6cdf:0x3ffbc0c0 0x400e9412:0x3ffbc0f0 0x400913c9:0x3ffbc110 Rebooting... |
|
I apologize for my ignorance, but how do I get the stack trace? |
|
re: stacktrace |
|
Maybe the nodeinfo changes from underneath it as it is drawing?
|
|
@girtsf yeah, but every time and this occurs early in the boot, before printing anything else. |
|
actually never mind. There must be something wrong with how I'm running exception_decoder. I just used a completely different backtrace and got the same output. Looking... |
|
yeah - I was dumb. fixing. |
|
better - this stack trace makes sense. Though it seems like a totally normal startup except we blew up the first time calling the esp library. Puzzling... I'll think about this later today. |
|
I am not a programmer but did manage to complete a project using two Heltec WiFi LoRa 32 (V2) boards and sample code from online. I would like to make more of them but also save some cash. Can I use my same code on the TTGO LORA32 version of the board? |
|
@Gotfrogs sorry - I didn't notice this comment until just now (for questions like this, probably faster response to post in the development forum on meshtastic.discourse.group) Are you asking about meshtastic? If so, it already runs on either the Heltec Lora32 or the TTGO lora32 (there are multiple build targets in our platformio.ini and we generated prebuilt bins for both of those boards). If you are asking about your own project, the two boards are almost the same - but a few gpios are different. See our configuration.h |
theory, it is the flash partitioning.
The text was updated successfully, but these errors were encountered: