As best as I can discern, the Crossworks default behavior is treat all loadable memory as RAM, but if the project provides a loader, *ALL* loading must be done by the loader.
This has a few disadvantages. One is that if some memory ranges are RAM, the loader must be coded to perform RAM initialization even though the direct RAM loading mechanism is much faster. Another is that loaders tend to use the very same RAM that needs to be initialized, so loading of these ranges is artificially prevented.
This situation happens with targets that have mask ROM bootloaders, "non-volatile SRAM"/"nvSRAM", FRAM, battery-backed SRAM, etc.
My suggestion would be that Loader-based memory regions could be programmed first (using the Loader), followed by RAM memory regions (using the direct RAM mechanism).
To determine which memory ranges are which, two possible approaches are:
Use the existing "access" tag in the Memory Map file to denote whether the Loader is applicable. "ReadOnly" presumably indicates Loader; "Read/Write" presumably indicates the RAM mechanism can be used.
Prior experience suggests that the Memory Map data is consulted before programming (either the compiled application or the "Additional Load File(s)").
HOWEVER, perhaps there are unanticipated corner cases where there are "Read/Write" regions that require a Loader? In that case...
Use an optional additional XML tag in the Memory Map file to indicate to not use the Loader.
#2 would have the benefit of being 100% compatible with existing Crossworks behavior. Only projects with Memory Maps using the additional tag could opt out of the Loader, in preference of the RAM mechanism, for particular regions.
Please sign in to leave a comment.