Wemos D1 Mini Pro not booting when referencing ArduinoOTA

crispinp · June 19, 2023, 10:22pm

Folks,

I got the weirdest issue.

I have a Wemos D1 Mini working just fine with a sketch. Sketch includes ArduinoOTA and that too worked well.

Today I changed the board to a new Wemos D1 Mini Pro, changed the ini, compiled and uploaded. No drama. Odd, board won’t boot.

I eventualy track it down to my file called OTA.cpp. In there I use the boilerplate OTA code.
When I comment it all out, the board runs fine.
When I put it back in but don’t refrence it, the board just crashes (see below).
Comment out the single line ArduinoOTA.setPassword(“FFF”), it compiles ok but the sketch refuses to run.
Remember, it’s in a funciton but not called!

This is the output

ets Jan 8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 3460, room 16
tail 4
chksum 0xcc
load 0x3fff20b8, len 40, room 4
tail 4
chksum 0xc9
csum 0xc9
v00045830
~ld
e:3
ets Jan 8 2013,rst cause:3, boot mode:(3,6)

ets_main.c

To recap

This worked on another board.
This does not work, even if code is there but not refrenced.

Ever seen anything like this?

maxgerhardt · June 20, 2023, 9:44am

Does the number of bytes in the Flash or RAM usage change in the final lines of the compilation log when you comment or uncomment the line? If yes, it’s not effectless after all.

crispinp · June 20, 2023, 7:31pm

Good shout - it is different.

With code:

RAM: [==== ] 41.2% (used 33748 bytes from 81920 bytes)
Flash: [=== ] 26.9% (used 280564 bytes from 1044464 bytes)

Without code:

RAM: [==== ] 40.8% (used 33428 bytes from 81920 bytes)
Flash: [=== ] 26.7% (used 278397 bytes from 1044464 bytes)

I also made a small test sketch which had only wifi and OTA and that worked perfectly.

So, on this board, OTA works but does not work with my sketch.

So confused…

crispinp · June 20, 2023, 7:38pm

Just tried it on a number of other boards. It fails on the pros, works fine on te d1-minis…

maxgerhardt · June 20, 2023, 7:44pm

A D1 mini pro has 16MByte of flash, which causes some problems in PlatformIO even during filesystem uploads.

github.com/platformio/platform-espressif8266

mkspiffs crashes when invoked with negative size parameter

opened 11:47AM - 13 Jan 20 UTC

maxgerhardt

bug

As detailed in https://community.platformio.org/t/building-uploading-spiffs-fail…s-error-3/11160/6?u=maxgerhardt, for the `platformio.ini`: ``` [env:d1_mini_pro] platform = espressif8266 board = d1_mini_pro framework = arduino ``` and creating a `data/` folder with one sample file inside it, the `pio run -t uploadfs` task will fail with a fatal error when creating the 14MB SPIFFS section, as dictated by the linker file, ``` "mkspiffs" -c data -p 256 -b 8192 -s -2121728 .pio\build\d1_mini_pro\spiffs.bin terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc ``` Because it cannot allocate `-2121728` bytes. The error lies within the correction code for the `SPIFFS_START` and `SPIFFS_END` variables which is done in this code https://github.com/platformio/platform-espressif8266/blob/b866c2952d4224f4e114e50144257acaf469839e/builder/main.py#L88-L111 The code transforms the original values ``` k = SPIFFS_START, value = 0x40400000 k = SPIFFS_END, value = 0x411fa000 ``` to ``` SPIFFS_END is -0x6000 SPIFFS_START is 0x200000 Diff is -0x206000 ``` thus yielding a negative length for the SPIFFS section. This error seems to occur for large 16MB / 128MBit flash chips. There might be other cases in which this correction logic is wrong? When `esptool` flash starts at 0 as the comment says, why not subtract the start address of the flash, `0x40200000`, from both addresses? I don't understand the correction logic at the moment.

Now while that exact bug may be unrelated, you can give it a try and make PlatformIO you have a more supported flash chip size, by adding

board_build.ldscript = eagle.flash.8m7m.ld

to the platformio.ini.