Boot loop on TTGO Lora Board

[sfabris]

Hi, first of all thanks for your effort in supporting different boards in pycom micropyrhon.

I'm trying to use your firmware on a couple of boards like these (http://www.lilygo.cn/prod_view.aspx?TypeId=50003&Id=1253&FId=t3:50003:3 , schematic should be https://github.com/LilyGO/TTGO-LORA32/blob/LilyGO-V1.3-868/lora_v1.3.pdf)

I tried with bot HELTEC and TTGO branch, flashed apparently successfully with make flash but not joy on powering on the boards:

TTGO branch: loops with: rst:0x10 (RTCWDT_RTC_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT) flash read err, 1000 ets_main.c 371

HELTEC branch: rst:0x1 (POWERON_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:1 load:0x3fff8020,len:4 load:0x3fff8028,len:2232 load:0x4009fa00,len:19572 entry 0x400a05c4 b��lc$�|��n���b lon��n��|�n�|�` œ�ܜ�ܜ�l

Do you have any idea on what could be wrong?

Thanks

Simone

[robert-hh]

As a first step, the Heltec WSL variant could end up with the wrong baud rate. So try a baud rate of 74880 or 177230. Besides that, there are man other settings which could be different. Hard to test w/o a board.

[sfabris]

Good... At 74880 I have a micropython prompt. I was suspecting the baud rate (clock on the board is 26 mhz, so a baud rate of 74880 seems correct if the image was built for 40 mhz).

I'm trying to check / investigate for other issue... In the meantime thanks for your support.

[robert-hh]

The attached schematics are labeled V1.1. And it may be a replica of an original TTGO board.

[robert-hh]

There is an inconsistency in the linked schematics with respect to the SX1276 reset line. At the chip, the line is labeled IO14, the box on the sheet says RESET=IO23. And that is a difference between the HELTEC_WSL and the TTGO build. The heltec build uses IO14, the TTGO build uses IO23. They also differ in which IO lines are used for DIO1 and DIO2, but it's not clear to me whether these are actually required. They are connected, but not mentioned. Maybe you could send me a picture of your board from the chip side.

[sfabris]

Thanks for the help, I think that If I can get the board to boot I will be able to figure out the pins mappings.

However, I can't get pycom to boot anymore :-( The boot with wrong baud rate was inconsistent. I believe that flash chip could not properly initiated due to the wrong on board crystal speed. I could get a boot prompt only a few times. Or maybe I was mix - matching different bootloaders and application.

So I took the road of updating ESP-IDF, based on this post: https://forum.pycom.io/topic/2835/is-it-possible-to-recompile-pycom-s-esp-idf-with-different-settings/2

With this I could get in the second stage bootloader:

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:1 load:0x3fff8020,len:4 load:0x3fff8028,len:8976 ho 0 tail 12 room 4 load:0x4009fa00,len:18768 entry 0x400a0de4 I (28) boot: ESP-IDF 2nd stage bootloader

Now I'm stuck here... apparently the 2nd stage bootloader is not returning from esp_rom_spiflash_unlock();

I think that I spent too much time with this board... If you don't have any clues I'm giving up

BTW, are you a beekeeper?

[robert-hh]

Last question first answered: No, I am not a beekeeper. Some people in the board are. Like I said, it is difficult for me to go ahead without that specific board, which also does not seem to match the TTGO specs. About the crystal: The frequency is printed on the package in very fine print. So you could look whether it is a 26 or 40 MHz crystal. By changing sdkconfig, you could set the crystal detection to "auto". Then you would rebuild libesp32.a for that. I did that for ESP32 Pico D support. But I have no real understanding about what all these config options do. Surely it is documented by espressif. If you like to do that, take any example from the esp-lib. Even the "hello world" example suffices.

[sfabris]

So, good news: I'm able to boot pycom micropython on this board after having update all the IDF static library.

Less good news Is that the inconsitency I had during the tests were related to a single board with secure boot enabled. As I don't have the signing key for the bootloader this particular board is gone. At least I can remove the esp32 chip and trace all the connections in order to validate the schematics.

I'm closing this issue now, I hope to submit you a PR for a working port for this particular board in the next few weeks, as soon as I have more boards to test.

Thanks again for your support.