This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

STM32 Flash compiler symbols

This is a bit of a noob question. I want to use a block of the STM32 flash in order to store some user data. So for example, the STM32F103ZE has 512KB flash & I want to use the top 64KB. The end user will have commands available in order to read & modify the data contained in this area.

The project option target tab shows that the start address is 0x8000000, & the size is 0x80000. So to allocate myself 64KB, I hve changed the size to 0x70000. So now I want to check during compilation that the target size never exceeds 0x70000, and if it does, to generate a build error, just in case someone else comes along and accidently sets the size back to 0x80000. I can't find what compiler symbol refers to the target size & start address. I can find the run-time symbols, but I would rather generate a compile error, rather than a run-time error. Does anyone please know how to implement this check?

regards

RTC

Parents
  • Yes, but said developers may just continue anyway - when getting an error, you fix the error :)

    The question here is if there is anything you can do, that these developers can't undo anyway.

    But you do have any form of testing with sign-off for each release, don't you? Such a test should include the use of the configuration sector. And it should include a manual or automatic verification that a full chip erase, followed by programming of the binary still leaves the 64kB in an erased state.

    A developer is likely to "fix problems", but a test document specifically requiring a verify that the last sector is erased does require a very dense developer to ignore, and just sign off a lie on the test protocol.

Reply
  • Yes, but said developers may just continue anyway - when getting an error, you fix the error :)

    The question here is if there is anything you can do, that these developers can't undo anyway.

    But you do have any form of testing with sign-off for each release, don't you? Such a test should include the use of the configuration sector. And it should include a manual or automatic verification that a full chip erase, followed by programming of the binary still leaves the 64kB in an erased state.

    A developer is likely to "fix problems", but a test document specifically requiring a verify that the last sector is erased does require a very dense developer to ignore, and just sign off a lie on the test protocol.

Children
No data