Trouble uploading .hex compiled by PIO to STM32 connected to VCON

Questions & Answers
#1

Hi!

I am having trouble uploading a .hex compiled by PIO to a STM32 connected to a CCM (ESP32).
Uploading the example blink .hex from the docs, seems to work without problems.

If I use the .hex compiled by PIO (Upload via mdash) I get the following error, while flashing to the STM32:

[Mar 9 21:02:59.630] ccm_fw_bundle_manif:174 Reached end of /data/ccm_0.bin
[Mar 9 21:02:59.635] ccm_host.cpp:196 Finished part, wrote 33660 bytes
[Mar 9 21:02:59.640] mgos_vfs.c:410 close 512 => 0x3ffb2460:0 => 0 (refs 0)
[Mar 9 21:02:59.647] ccm_fw_bundle_manif:135 Opening /data/ccm_1.bin (addr 0x8008380)
[Mar 9 21:02:59.652] mgos_vfs.c:283 /data/ccm_1.bin -> /data/ccm_1.bin pl 5 -> 2 0x3ffb2460 (refs 1)
[Mar 9 21:02:59.662] mgos_vfs.c:377 open /data/ccm_1.bin 0x0 0x1b6 => 0x3ffb2460 ccm_1.bin 0 => 512 (refs 1)
[Mar 9 21:02:59.671] ccm_host.cpp:179 Writing part at 0x08008380
[Mar 9 21:02:59.675] mgos_vfs.c:536 fstat 512 => 0x3ffb2460:0 => 0 (size 6192)
[Mar 9 21:02:59.682] ccm_host_ota_stm32.:158 Exiting bootloader...
[Mar 9 21:02:59.691] ccm_host.cpp:313 Host mode: RPC
[Mar 9 21:02:59.695] mg_rpc.c:470 0x3ffb3eb4 CHAN OPEN (UART UART1)
[Mar 9 21:02:59.700] mgos_event.c:135 ev RPC0 triggered 1 handlers
[Mar 9 21:02:59.705] ccm_host_ota_backen:192 Host update finished: -103 UpdateFromBundle : Erase 256 @ 0x8008380 : Address 0x8008380 is not at page boundary
[Mar 9 21:02:59.717] mgos_vfs.c:410 close 512 => 0x3ffb2460:0 => 0 (refs 0)
[Mar 9 21:02:59.723] mgos_ota_core.c:773 0: 2 0
[Mar 9 21:02:59.726] mgos_ota_core.c:785 1: 1 3
[Mar 9 21:02:59.729] mgos_ota_core.c:265 Update state 7 -> 8
[Mar 9 21:02:59.733] mgos_ota_core.c:811 Update finished, result -15 (UpdateFromBundle : Erase 256 @ 0x8008380 : Address 0x8008380 is not at page boundary)
[Mar 9 21:02:59.745] mgos_vfs.c:283 updater.dat -> /updater.dat pl 1 -> 1 0x3ffd2acc (refs 1)
[Mar 9 21:02:59.754] mgos_vfs.c:377 open updater.dat 0x0 0x1b6 => 0x3ffd2acc updater.dat -1 => -1 (refs 0)
[Mar 9 21:02:59.763] mg_rpc.c:233 'wss://mdash.net/api/v2/rpc' -> 0x3ffb22b0
[Mar 9 21:02:59.770] mg_rpc.c:612 0x3ffb22b0 SEND FRAME (268): {"src":"ccm_95E748","method":"Dash.Shadow.Update","params":{"state": {"reported": {"ota":{"message": "UpdateFromBundle : Erase 256 @ 0x8008380 : Address 0x8008380 is not at page boundary", "status": 2, "is_committed": true, "partition": 0, "progress_percent": 100}}}}} -> 1
[Mar 9 21:02:59.799] mgos_event.c:135 ev SDW1 triggered 1 handlers
[Mar 9 21:02:59.804] mgos_event.c:135 ev OTA1 triggered 3 handlers
[Mar 9 21:02:59.809] mg_rpc.c:631 QUEUED FRAME (149): {"id":26,"src":"ccm_95E748","error":{"code":-1,"message":"-15 UpdateFromBundle : Erase 256 @ 0x8008380 : Address 0x8008380 is not at page boundary"}}
[Mar 9 21:02:59.827] mg_rpc.c:508 0x3ffb22b0 FRAME SENT (1)
[Mar 9 21:02:59.832] mg_rpc.c:612 0x3ffb22b0 SEND FRAME (149): {"id":26,"src":"ccm_95E748","error":{"code":-1,"message":"-15 UpdateFromBundle : Erase 256 @ 0x8008380 : Address 0x8008380 is not at page boundary"}} -> 1
[Mar 9 21:02:59.852] mg_rpc.c:508 0x3ffb22b0 FRAME SENT (1)

Any ideas what could be wrong?

Probably some error in the .hex compiled by PIO?

Thanks!

#2

The root cause lies in a fact that the generated .hex file has a 4 byte gap in the middle, thus mDash creates two different firmware parts which are 4 bytes apart - and they are of course not page-aligned. Here is the respective .hex file part:

10 3200 00 310100081D05000841260008F8B500BF 7F
0C 3210 00 F8BC08BC9E467047ED000008 AA
08 3220 00 14D1FF7F01000000 42
10 3228 00 00000000000000000000010014000020 61

The chunk at address 3210 is 12 bytes long, and next chunk starts at 3220, leaving 4 bytes gap.
The solution here is to add a padding of four 0xff bytes, that are going to fill the gap. I guess there is some tool that inserts extra records to fill the gap, regenerating the .hex file.

#3

@steffentrumpf mDash has been updated to automatically fill gaps less than 512 bytes with 0xff. Please try to OTA using .hex file - it should succeed.

#4

Thank you very much for investigating and the quick fix!
Everything works as expected now!
Thanks!