Loading code to on-board 6455 SRAM
(posted on behalf of a customer using MityDSP-Pro)
I have so far only loaded & run via CCSv5, but soon I will want to run via boot from a hex file stored in FLASH. However, I see an ominous note under "IRAM" on pg 28 of your Day-1 PM Training slides: "Note: Current bootloader doesn’t support loading code to IRAM from FLASH." I think I saw that elsewhere in the training slides. Is that still the case? If so, can the bootloaded load into L1P? How do I make this work? I need to put code & data into L1P, L1D, & L2, since there is not enough room in L1P & L1D, and DDR2 is way too slow.
At the moment, your observation is correct, the current bootloader does not support loading code directly to anywhere other than DDR2 from FLASH with the hex images provided. Initialized DATA (via cinit) should be OK. The issue has to do with how the .hex file is stored in FLASH by the bootloader applications software.
Typically, other customers enable caching (L1, and L2), which effectively pulls the tight loop code in from the slower DDR2 into the caches during runtime.
If you are disabling the caches (our default BIOS template files enable them, so make sure you go back through and turn them all off) and dropping code directly into IRAM (L2 or L1), you're going to need write some code to relocate it from DDR2 back into the internal memories as part of the startup sequence. I know that's not a great answer. Sorry.
RE: Loading code to on-board 6455 SRAM - Added by Bob Clarke almost 9 years ago
how does the bootloader work? If my code stored in FLASH is linked such that part of should be located in L1 or L2, does the bootloader just ignore it or does it somehow put everything in the DDR2 memory?
RE: Loading code to on-board 6455 SRAM - Added by Dave Stehlik almost 9 years ago
It will copy from the flash to DDR2 then pass execution to DDR2. It is simple copy
which does not have the facility to copy to different addresses.