Did you mean to say "fit the whole thing in RAM"??Since I'm confident I can fit the whole thing in flash I was intending a NO_FLASH build. At that point I wanted to attempt writing some runtime data logging to flash , so no XIP needed.
Unless you are doing something unusual, you don't want a NO_FLASH build - that's for when you download the image (eg. over USB) every time and don't store the code in flash at all. If that's what you actually want it could work but with the extra complication of needing to set up the flash from scratch (normally the SDK flash read/write functions expect to find the flash already set up for XIP and just need to tweak it to do writing).
Much more likely, you want a COPY_TO_RAM build. That sets up the XIP to do the copy into RAM, but doesn't use it thereafter, leaving the flash freely available for writing regardless of what your program is doing.
The tricky case is the standard build with most of the code XIP but selected interrupt handlers etc marked __not_in_flash_func(). That's where you have to be really careful that code you are assuming executes from RAM isn't ever touching flash.
The gotchas on writing are as above - so COPY_TO_RAM avoids them.I have not got as far as looking at how to allocate and write to the onboard flash. Any gotchas I need to look out for there?
On allocation, code normally starts at low addresses and works up, so you can either pick a "my code will never get bigger than this" address and start from there (good if you want to maybe support boards with bigger flash chips), or else start from the end and work backwards.
Remember that flash isn't infinite life, so if your application gets stopped and restarted often then you really want to allocate circularly so as to not keep thrashing the same pages.
Statistics: Posted by arg001 — Sun Nov 24, 2024 12:48 pm