I'm using the Keil simulator to check that my flash write operations are working. When I call the STM driver command to write to flash, it "succeeds", in that no errors are thrown, but the memory remains unchanged. I have mapped that section of memory as read and write using a *.ini.
Someone had a similar issue, but on a different architecture, but there is no solution stated.
http://www.keil.com/forum/22207/
I've tried simply writing data to that address (something that I don't expect would work if run on the actual MPU), but that also doesn't work.
Any input would be greatly appreciated!
In my case it would be very nice - the aim is to store double buffered settings in flash, and I would like to write unit tests to verify this works properly
Anyways, I did finally manage to get around this. Originally the settings were in the first segment of flash memory, and the application was programmed further down (this way the application can grow and there is no need to worry about reshuffling where the settings sit). But Keil seems to just block that whole section of memory when simulating, so that you cannot edit it. If I try edit the section of memory after the application, it works like RAM memory - you can just edit it as you need. Although this isn't ideal, it should be enough for now.
I have done this, and it worked well. Keil does not have any built in support and in this case I would not expect simulation support. One of the chips I have used this on utilize a hidden ROM section to program flash ... it is not readily available or documented.
It took a sim script to write the simulated flash and report status. Sim script was triggered by address writes to dedicated trigger variables. I used conditionally compiled copies of the chip's flash write library. The flash write / status functions were modified to write variables / special addresses to kick off the sim script so that the same function calls were used for hw or simulation builds.
You will need to map the desired areas to read / write / execute as necessary.
Hope this helps, Chad