I created read/write functions
memcpy(&sys_parameters, &FlashMemory.buf, sizeof(SYS_PARAMS));
memcpy(&FlashMemory.buf, &sys_parameters, sizeof(SYS_PARAMS));
When I invoke SYS_ParamWrite() I’m stuck in the function. Probably some hardware exception due to memory access.
What is wrong with my method?
Ooops…Just my typo
memcpy(&sys_parameters, FlashMemory.buf, sizeof(SYS_PARAMS));
memcpy(FlashMemory.buf, &sys_parameters, sizeof(SYS_PARAMS));
And I set an option - erase the page before write
Now it’s OK but after a restart - no parameters are saved.
Hi @john7 Thanks for providing the detailes,
May I know what you put for the base address? and approx how big is your data being stored?
I don’t do it explicitly
because it’s initialized in the class
FlashMemoryClass FlashMemory = FlashMemoryClass(FLASH_MEMORY_APP_BASE, FLASH_SECTOR_SIZE);
Structure size about 512 bytes.
I thought because my struct is not packed it’s not aligned properly, so I did a test
//memcpy(FlashMemory.buf, &sys_parameters, sizeof(SYS_PARAMS));
FlashMemory.buf = sys_parameters.debug; //uint8_t
//memcpy(&sys_parameters, FlashMemory.buf, sizeof(SYS_PARAMS));
sys_parameters.debug = FlashMemory.buf;
The parameter is not saved.
Ohhh…Sorry. It seems like the problem because my struct is not packed.
I also want to use the FlashMemory.h functions on a BW16 module.
I am concerned about how FLASH_MEMORY_APP_BASE works.
I can see it is set to 0x0010 0000, but referring to the datasheet for the RTL882XD, that address is marked as “RSVD”, persumably meaning ‘reserved’.
According to the same datasheet (and indeed the addresses in which programs are stored), the flash memory seems to start at 0x0800 0000
How, then is 0x0010 0000 a ‘safe’ address to use?
Also, is there a way of preserving the information in this block through a firmware update? I guess I could use a custom updater which reads the data then writes it back - perhaps somebody has done this already? It must be a common reqirement (e.g. to retain IP address, network SSID etc)
you should also refer to chapter 9 of AN0400 Application note, which provides the default flash layout.
Flash memory indeed starts at address 0x0800_0000,
FLASH_MEMORY_APP_BASE is used more like an offset, with the code internally adding in the starting flash address.
Chapter 9 shows that using an offset of 0x0010_0000 places the data in the
User Data section of flash memory. You can also choose to change the code and shift this to the end of the flash memory region.
Thankyou - I thought I’d ‘fully digested’ AN400, but I’d missed that very useful table!
And so far as I can see, the standard erase functions in upload_image_tool_windows.exe appears to leave 0x0810_0000 un-touched, which solves the problem of retention.