We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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
Hello Per,
Thank you for your reply. I agree with your statement, but unfortunately I have worked with engineers in the past who have changed project settings without understandng the full implications of what they are doing. They add additional functionality & project size ends up exceedng the allocated size, so they simply change the allocated size back to it's maximum value & carry on.
I was looking for a way of checking that the target settings hadn't changed so preventing the user defined data overwriting an area of flash that may contain the application code. I figured preventing a successful build was the best way of ensuring that the area of flash I wanted to use was reserved for my use only.
I like to think of it as paranoid coding.
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.