Bug in hrs example?

RE: Bug in hrs example?

FormerMember — Fri, 09 Jun 2017 10:23:20 GMT

I have updated my answer to answer your question.

RE: Bug in hrs example?

Michal — Thu, 08 Jun 2017 08:04:42 GMT

Ok, I saw your answer but I already knew all of that. Let me put it other way on base of hrs example. Assume I have board with your hrs example. During life of application it saved some peer info via fds on flash (last 4 pages - 3 + 1 swap). Now application for some reason grew in size and now it has 0x61000 bytes. Flash region has exactly enough space for it. But at the end of the flash i have my fds pages ! I understand they will be overwritten when flashing application without any warning ! Isn't that a bug ? Shouldn't space for code be define as 0x6100 - fds_pages * 0x1000? What's more when I flash my application it will run ok but on first write by fds it will overwrite its code giving unexpected behaviour and potentially a crash.

To the point. As I wrote in post - shouldn't FLASH region be 0x5d00?

RE: Bug in hrs example?

FormerMember — Thu, 08 Jun 2017 07:18:56 GMT

That memory section in the linker script tells which part of flash and RAM that is available for the application (including the FDS).

This answer explains where FDS data will be stored in flash.

Update 09.06.2017: Yes, you are right, the application could potentially overwrite the FDS space. So yes, changing the compilation flash settings to exclude the FDS space is the right thing to do, and the flash region length should be 0x5D000.

Note: FDS will not override the application.