I have a problem with some program instructions being overwritten by my application. I am using dual core BF561 with two applications (one per core), external SDRAM, VDSP++ v5 update 8, and multiple threads per core with VDK. I am programming with HPUSB-ICE.
The application on core a appears to work successfully with no issues but the core b application seems to get corrupted at instruction address 0xFEB01264. Using expert linker i can see that the memory segment mem_b_l2_sram occupies the range 0xFEB00000 to 0xFEB07FFF. Within this segment there is an output section called l2_sram_b which uses memory addresses 0xFEB00000 to 0xFEB04E77. This output section (according to expert linker) contains only *.doj and *.dlb program data.
The corruption occurs when a memcpy command executes. The memcpy is the C++ instrucyion immediately prior to the instructions that appear to get corrupted. If I put a break point before the memcpy command then the instructions (in the disassembly window) that follow the memcpy command are ok. If I then step over the memcpy command the instructions remain ok. However, if I put a break point after the memcpy the instuctions at the break point (and for a couple of instructions after the break point are corrupted (different from before). It would appear that the memcpy is actually writing data to the location of the next instruction rather than to the memory location pointed to by the first argument of the memcpy call. I have tried hard wiring the write to address in the memcpy command (to a sdram location of 0x02962570) but this makes no difference.
I'm wondering if the memcpy is actually the problem. It may be that another thread (or driver) is doing something else that has caused the corruption and that the memcpy command uses extra time that allows the corruption to occur. However, it is would be a large co-incidence that it was corrupting the instructions that immediately follow the call to memcpy. I have also wondered if some previous corruption of the memcpy command has occured which means that the application uses the current instruction address (rather than the correct address) as the write to address for the memcpy command.
What is more wierd is that the corruption appears to come and go depending which other bits of code I include in the build. I have a driver which when included causes the fault but when not the fault goes away. However, if the driver is never called it still causes the problem. If I remove the driver, the problem clears. If I then add some other VDK threads and code the problem comes back (still with no driver). It is as though the problem is related to how much code is being loaded (but there are no memory conflicts in expert linker).
I have also looked at the stack ussage in VDK which appears to be fine, the stack size for each is 511 words, VDK status window says that the max used words for each of the threads is ~150.
I have also wondered if the corruption is real, or an artifact of the HPUSB-ICE debugging. However, when I break after the memcpy command and I see corrupt instructions, if I then release the core it typically goes to the exception handler. The exception is often 0x21 (invalid instruction) which implies that the instructions really are corrupt.
I have looked through the code and can't see a place where I might be writing data to a memory location.
I'm sure there must be something simple I have done (a setting or something). Any thoughts?