[Solved] WiFi LoRa 32 (V3) Software breaks WiFi LoRa 32 V1

#1

Having just upgraded my [macOS 10.14.5] Arduino IDE (2.0.2) installation to support the new V3 boards I find that I can no longer successfully upload software to my V1 boards if I choose the ‘WiFi LoRa 32’ option from the [new] Tools > Board > Heltec-ESP-32 Series Dev-boards menu. The board goes into infinite reboot with the following messages:

16:01:21.104 -> ELF file SHA256: 0000000000000000
16:01:21.104 -> 
16:01:21.104 -> Rebooting...
16:01:21.104 -> ets Jun  8 2016 00:22:57
16:01:21.104 -> 
16:01:21.104 -> rst:0xc (SW_CPU_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
16:01:21.137 -> configsip: 0, SPIWP:0xee
16:01:21.137 -> clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
16:01:21.137 -> mode:DIO, clock div:1
16:01:21.137 -> load:0x3fff0030,len:1184
16:01:21.137 -> load:0x40078000,len:13160
16:01:21.137 -> load:0x40080400,len:3036
16:01:21.137 -> entry 0x400805e4
16:01:21.240 -> E (115) spi_flash: Detected size(4096k) smaller than the size in the binary image header(8192k). Probe failed.
16:01:21.240 -> 
16:01:21.240 -> assert failed: do_core_init startup.c:298 (flash_ret == ESP_OK)
16:01:21.240 -> 
16:01:21.240 -> 
16:01:21.240 -> Backtrace:0x400832ed:0x3ffe3aa00x40087155:0x3ffe3ac0 0x4008bc65:0x3ffe3ae0 0x400d5912:0x3ffe3c10 0x40082a09:0x3ffe3c40 0x400792ba:0x3ffe3c90  |<-CORRUPTED

I find that I can still upload sketches if I choose ‘Heltec WiFi LoRa 32’ from the Tools > Board > ESP32 Arduino menu, so all is not lost, but there would appear to be a problem with whatever has changed between the old and the new arrangement.

Presumably, at some point in the future, the more recently included V1 board definition, the one that’s failing, will be the only one available so this problem really needs to be resolved before the old board definition disappears.

Uploads to V2 boards seem to be OK whichever [V2] menu option is chosen.

#2

Which routine did you choose?
The previous libraries have been merged, so they have not been updated.

#3

Sorry, I’m not sure what you mean by ‘routine’.

I haven’t been able to successfully load any sketch to a WiFi LoRa 32 [V1] board if I select ‘WiFi LoRa 32’ from the Tools > Board > Heltec-ESP-32 Series Dev-boards menu. This is a new menu that appeared when I installed the new V3 support software. Prior to that, I would select ‘Heltec WiFi LoRa 32’ from the Tools > Board > ESP32 Arduino menu.

Both menu options now exist but the new one results in a continuous reboot cycle (see above) after any sketch load. The old one works as it always has.

The simplest example is the Blink sketch. The results of loading this sketch on V1, V2 and V3 boards are as follows:

Board    ESP32 Arduino menu   Heltec ESP32 Series Dev-boards menu
 V1        Loads & Runs         Loads & Continuous reboot
 V2        Loads & Runs         Loads & Runs
 V3            N/A              Loads & Runs (using GPIO35 for LED)

By way of further example, I have also tried to load (using the Tools > Board > Heltec-ESP-32 Series Dev-boards > WiFi LoRa 32 board selection) the Examples > Examples for WiFi LoRa 32 > ESP32 > ChipID > GetChipID and Examples > Examples for WiFi LoRa 32 > Heltec-Example > OLED > SSD1306_I2C > SimpleDemo sketches and they both result in the same problem—infinite reboot cycle.

#4

I’ve just done a completely clean install in a new user area and the only thing that has been added to the Arduino IDE (2.0.2) (through the Board Manager) is the Heltec ESP32 Series Dev-boards (0.0.7) board definition file, and the result is the same: V2 and V3 are OK, but V1 just goes into continuous reboot. But, of course, I now no longer have the old definition to fall back on…

#5

PROBLEM SOLVED: After locating the respective boards.txt files, and noting the line in the error message:

16:01:21.240 -> E (115) spi_flash: Detected size(4096k) smaller than the size in the binary image header(8192k). Probe failed.

I believe the problem was simply that there are some incorrect entries in the new boards.txt file.

The old boards.txt file includes the following build parameters:

heltec_wifi_lora_32.build.f_cpu=240000000L
heltec_wifi_lora_32.build.flash_size=4MB
heltec_wifi_lora_32.build.flash_freq=80m
heltec_wifi_lora_32.build.flash_mode=dio
heltec_wifi_lora_32.build.boot=dio
heltec_wifi_lora_32.build.partitions=default
heltec_wifi_lora_32.build.defines=-D{build.band} -DLoRaWAN_DEBUG_LEVEL={build.LoRaWanDebugLevel} -DACTIVE_REGION=LORAMAC_{build.band} {build.psram}

The new boards.txt file includes the following build parameters:

wifi_lora_32.build.f_cpu=240000000L
wifi_lora_32.build.flash_size=8MB
wifi_lora_32.build.flash_freq=80m
wifi_lora_32.build.flash_mode=dio
wifi_lora_32.build.boot=dio
wifi_lora_32.build.partitions=default_8MB
wifi_lora_32.build.defines=-D{build.band} -DLoRaWAN_DEBUG_LEVEL={build.LoRaWanDebugLevel} -DACTIVE_REGION=LORAMAC_{build.band} -DLORAWAN_PREAMBLE_LENGTH={build.LORAWAN_PREAMBLE_LENGTH} -DLORAWAN_DEVEUI_AUTO={build.LORAWAN_DEVEUI_AUTO} -D{build.board}
wifi_lora_32.build.extra_libs=-lheltec

Note the reference to size in the error message (4096k detected vs 8192k in the image header) and the discrepancy between the flash_size settings in the respective boards.txt files.

Changing the settings in the new boards.txt file to match those in the old, in particular:

wifi_lora_32.build.flash_size=4MB
wifi_lora_32.build.partitions=default

resolves my immediate issue and sketches now load and run as expected.

There are several other entires for the WiFi LoRa 32 [V1] dev-board in the boards.txt files that do not match, but I have left them alone for the time being (because I don’t really know what they do). Could I request that someone from Heltec rectify the present problem in future releases and verify that all of the current entries are appropriate?

1 Like
#6

Because the V1 version has been off the market for a long time, it has not been updated. But if the customer needs, we will continue to update.

#7

I think the problem is that the boards.txt file entries for the V1 board WERE updated, but perhaps not intentionally. It seems that all that would be required is for the V1 board definition from, say, the esp32/1.0.6/boards.txt file be reproduced in the current Heltec-esp32/0.0.7/boards.txt file (and carried through without change to any future release).

Given that the current definition in the 0.0.7/boards.txt file results in the presently described fault, there’s not really any point in having it there at all. At least, if there was no definition at all, a user would know that they had to go find it somewhere else. In this respect, having something that is faulty is worse than having nothing at all…

But I think the fix, in the present case, would be pretty simple. It would just be nice if the user didn’t have to do this every time an update was released. :slightly_smiling_face:

1 Like
#8

Thank you very much for your suggestions. We will update the relevant configuration files later.