Assert in _fs_verify_magic fails on new B_L072Z_LRWAN1 devboard about sub-iot-stack HOT 7 CLOSED

So I got it working using the workaround you posted. That post is a bit outdated and the stlink tool became more capable in the meantime, which was nice.

Here are the steps I had to take. Might be useful for some.

There are 2 linker sections that need to go to eeprom:

• .d7ap_fs_metadata_section
• .d7ap_fs_permanent_files_section

We need to copy those to a separate binary file. But first we need to know the starting addresses for those sections:

arm-none-eabi-objdump --headers gateway.elf

gateway.elf:     file format elf32-littlearm


Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00015ec8  08000000  08000000  00010000  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .ARM.exidx    00000008  08015ec8  08015ec8  00025ec8  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .d7ap_fs_metadata_section 00000bfc  08080000  08080000  00040000  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  3 .d7ap_fs_permanent_files_section 0000076c  08080bfc  08080bfc  00040bfc  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  4 .stack        00000500  20000000  20000000  00050000  2**0
                  ALLOC
  5 .data         000000d0  20000500  08015ed0  00030500  2**2
                  CONTENTS, ALLOC, LOAD, DATA

The first section (.d7ap_fs_metadata_section) starts at 0x08080000 (=0x0 for eeprom) and has size 0xbfc. So that is where the next section (.d7ap_fs_permanent_files_section) starts. We can now use these numbers to copy that data to a new hex file and then create the binary:

arm-none-eabi-objcopy \
-j .d7ap_fs_metadata_section --set-section-flags=.d7ap_fs_metadata_section="alloc,load" --change-section-lma .d7ap_fs_metadata_section=0 \
-j .d7ap_fs_permanent_files_section --set-section-flags=.d7ap_fs_permanent_files_section="alloc,load" --change-section-lma .d7ap_fs_permanent_files_section=0xbfc \
-O ihex gateway.elf gateway.eep.hex

# Create binary from intel hex
arm-none-eabi-objcopy -I ihex -O binary gateway.eep.hex gateway.eep.bin

Finally we can flash the eeprom data using the modified stlink tool as described in the blogpost. For example using this fork.

./st-flash --reset write build/apps/gateway/gateway.eep.bin 0x08080000

st-flash 1.5.1-50-g3690de9
2019-11-11T08:55:16 INFO common.c: Loading device parameters....
2019-11-11T08:55:16 INFO common.c: Device connected is: L0x Category 5 device, id 0x20086447
2019-11-11T08:55:16 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x1911c00 bytes (25671 KiB) in pages of 128 bytes
2019-11-11T08:55:16 INFO common.c: Ignoring 144 bytes of 0x00 at end of file
2019-11-11T08:55:16 INFO common.c: Attempting to write 4824 (0x12d8) bytes to stm32 address: 134742016 (0x8080000)
Flash page at addr: 0x08081280 erased
2019-11-11T08:55:17 INFO common.c: Finished erasing 38 pages of 128 (0x80) bytes
2019-11-11T08:55:17 INFO common.c: Starting Half page flash write for STM32L core id
2019-11-11T08:55:17 INFO flash_loader.c: Successfully loaded flash loader in sram
 75/75 halfpages written
2019-11-11T08:55:22 INFO common.c: Starting verification of write complete
2019-11-11T08:55:22 INFO common.c: Flash written and verified! jolly good!

from sub-iot-stack.

Oh and by the way, I figured out that with the Black Magic Probe you can just use the original ELF file, and it will automatically flash the code and eeprom correctly. So that's even easier if you have a BMP.

from sub-iot-stack.

The code expects the EEPROM to be flashed correctly, which is done by for example the make flash-sensor_push (or make flash-sensor_push-fs) target. This assumes JLink however. I suspect that stlink / openocd does not write to the embedded EEPROM of the STM32L. I have no experience with stlink or openocd but a quick search seems to confirm this. A workaround might be to use st-flash to write the EEPROM as described here.

Otherwise I suggest to reflash the stlink with the JLink firmware as described in the docs. That way you can use the make targets to write the EEPROM.

from sub-iot-stack.

Ah Thanks! I'll try out the workaround and as a last resort convert to JLink.

from sub-iot-stack.

Good to hear and thanks for the write-up!
As an additional comment: the cmake build already generates an hex file the eeprom sections, for instance apps/gateway/gateway-eeprom-fs.hex, so I think you can save a few steps by using this

from sub-iot-stack.

I noticed that, but that one turned out to be empty.

I just did a quick search and I think the section names have been renamed at some point, but not in the cmake file.
in app_macrs.cmake the section are called ".d7ap_fs_metadata", ".d7ap_fs_file_headers", ".d7ap_fs_systemfiles" but in the code and linker file they are .d7ap_fs_metadata_section, .d7ap_fs_permanent_files_section

from sub-iot-stack.

I just did a quick search and I think the section names have been renamed at some point, but not in the cmake file.

You are completely correct, I seem to have forgotten to change this in cmake and docs.
Thanks for the PR!

from sub-iot-stack.