Hi
Compile the cli sample into a hex file,Download it to the board, read the hex file through the nRF Connect for Desktop Programmer tool, and then convert it to the bin file through the hex2bin tool. Compared with the original bin file, it is found that the last six bytes of the flash application partition have 00 00 00 00 AF changes
I'm worried that this problem will damage the flash
Hi,
From which nRF Connect SDK version did you build the OpenThread CLI example?
I suspect that the change in flash that you are seeing is a page tag or similar for the Non-Volatile Storage (NVS) library, used by the Settings module to store OpenThread persistent data (network keys, dataset, etc). The address does not match the one I see from my build in NCS 2.1.0 (0x7CFF2), but the content does. Once you have entered ot commands into the CLI and started the Thread stack, the flash area will be filled with more data. Why are you concerned that this will damage the flash? If you do not want the information stored into the flash of the device, the device would lose information about the Thread network each time the power is lost.
Best regards,
Jørgen
Hi
I conducted a data write test from cli to flash, and found that the data storage location is 0x75000 to 0x77000, and different from the pm_static.yml I defined. Why
Looking forward to your reply
E:\ncs18\nrf\samples\openthread\cli> west build -t partition_manager_report --board=nrf52833dk_nrf52833 -- west build: generating a build system Including boilerplate (Zephyr base (cached)): E:/ncs18/zephyr/cmake/app/boilerplate.cmake -- Application: E:/ncs18/nrf/samples/openthread/cli -- Zephyr version: 2.7.0 (E:/ncs18/zephyr), build: v2.7.0-ncs1 -- Found west (found suitable version "0.12.0", minimum required is "0.7.1") -- Board: nrf52833dk_nrf52833 -- Cache files will be written to: E:/ncs18/zephyr/.cache -- Found dtc: C:/ProgramData/chocolatey/bin/dtc.exe (found suitable version "1.5.0", minimum required is "1.4.6") -- Found toolchain: gnuarmemb (c:/gnuarmemb) -- Found BOARD.dts: E:/ncs18/zephyr/boards/arm/nrf52833dk_nrf52833/nrf52833dk_nrf52833.dts -- Found devicetree overlay: E:/ncs18/nrf/samples/openthread/cli/boards/nrf52833dk_nrf52833.overlay nrf52833dk_nrf52833.dts.pre.tmp:57.26-59.5: Warning (simple_bus_reg): /soc/memory@20000000: simple-bus unit address format error, expected "20000008" also defined at nrf52833dk_nrf52833.dts.pre.tmp:412.8-414.3 also defined at nrf52833dk_nrf52833.dts.pre.tmp:624.8-627.3 unit address and first address in 'reg' (0x20000008) don't match for /soc/memory@20000000 -- Generated zephyr.dts: E:/ncs18/nrf/samples/openthread/cli/build/zephyr/zephyr.dts -- Generated devicetree_unfixed.h: E:/ncs18/nrf/samples/openthread/cli/build/zephyr/include/generated/devicetree_unfixed.h -- Generated device_extern.h: E:/ncs18/nrf/samples/openthread/cli/build/zephyr/include/generated/device_extern.h -- Including generated dts.cmake file: E:/ncs18/nrf/samples/openthread/cli/build/zephyr/dts.cmake warning: Experimental symbol NET_CONNECTION_MANAGER is enabled. Parsing E:/ncs18/nrf/samples/openthread/cli/Kconfig Loaded configuration 'E:/ncs18/zephyr/boards/arm/nrf52833dk_nrf52833/nrf52833dk_nrf52833_defconfig' Merged configuration 'E:/ncs18/nrf/samples/openthread/cli/prj.conf' Configuration saved to 'E:/ncs18/nrf/samples/openthread/cli/build/zephyr/.config' Kconfig header saved to 'E:/ncs18/nrf/samples/openthread/cli/build/zephyr/include/generated/autoconf.h' C:\gnuarmemb\bin\arm-none-eabi-gdb.exe: warning: Couldn't determine a path for the index cache directory. -- The C compiler identification is GNU 9.2.1 -- The CXX compiler identification is GNU 9.2.1 -- The ASM compiler identification is GNU -- Found assembler: C:/gnuarmemb/bin/arm-none-eabi-gcc.exe -- OpenThread Source Directory: E:/ncs18/modules/lib/openthread -- Check if the system is big endian -- Searching 16 bit integer -- Looking for sys/types.h -- Looking for sys/types.h - found -- Looking for stdint.h -- Looking for stdint.h - found -- Looking for stddef.h -- Looking for stddef.h - found -- Check size of unsigned short -- Check size of unsigned short - done -- Searching 16 bit integer - Using unsigned short -- Check if the system is big endian - little endian -- Package Name: OPENTHREAD -- Package Version: v0.0.2 CMake Warning at E:/ncs18/zephyr/CMakeLists.txt:1662 (message): __ASSERT() statements are globally ENABLED -- Found partition manager static configuration: E:/ncs18/nrf/samples/openthread/cli/pm_static.yml Partition 'settings_storage' is not included in the dynamic resolving since it is statically defined. -- Configuring done -- Generating done -- Build files have been written to: E:/ncs18/nrf/samples/openthread/cli/build -- west build: running target partition_manager_report [1/1] cmd.exe /C "cd /D E:\ncs18\nrf\samples\openthread\cl... E:/ncs18/nrf/samples/openthread/cli/build/partitions.yml" flash_primary (0x80000 - 512kB): +-----------------------------------------------+ | 0x0: MBR (0x1000 - 4kB) | | 0x1000: app (0x75000 - 468kB) | | 0x76000: settings_storage (0x2000 - 8kB) | | 0x78000: dfu_bootloader (0x6000 - 24kB) | | 0x7e000: MBR_parameter_storage (0x1000 - 4kB) | | 0x7f000: Bootloader_settings (0x1000 - 4kB) | +-----------------------------------------------+ sram_primary (0x1fff8 - 127kB): +--------------------------------------------+ | 0x20000008: sram_primary (0x1fff8 - 127kB) | +--------------------------------------------+
It looks correct. Did you perform an eraseall operation on the board before programming the new application? If the library finds existing pages in flash, it might reuse these instead of creating new pages. The library will not erase existing filled pages unless you explicitly does so in the application.
nrfjprog -e -f NRF52 && nrfjprog --program openthread_cli_0.0.2_v2-1019.hex -f NRF52 && nrfjprog --verify openthread_cli_0.0.2_v2-1019.hex -f NRF52 && nrfjprog --reset -f NRF52 Erasing user available code and UICR flash areas. Applying system reset. Parsing image file. Verified OK. Verifying programming. Verified OK. Applying system reset. Run.This is my upgrade command and the generated log
I think the flash has been erased
Hi
I tested the CLI source code,Write data to flash,The 1k address before the 00 00 00 00 00 AF tag starts to be stored, which is similar to the CLI program of the customized partition after modification.
How is the 00 00 00 00 00 AF tag defined? It may be used in programs.
The tag seems to be written at run-time. I could not see any tags defined directly as 0xAF, so an approach might be to erase the flash, program the sample, and step through the code the first time it runs, and see at what time / what function call is doing the writing to this address.
The tag seems to be written at run-time. I could not see any tags defined directly as 0xAF, so an approach might be to erase the flash, program the sample, and step through the code the first time it runs, and see at what time / what function call is doing the writing to this address.
