hello,
I have a code for Concerto F28M35H52C1 that runs to NMI and ILLEGAL trap of C28 core. The trap is triggered when a loop used to read a block of data (stored into L1 RAM sector) is run, but this may or not may happen depending on what is done in surrounding code that is not even related at all with data reading. The piece of code looks like:
Uint32 statusVars[STATUS_SIZE];
Uint32 *pStatusVars[STATUS_SIZE];
// dummy = 0; // this line triggers the NMI + ILLEGAL traps
for(i=0; i<STATUS_SIZE; i++)
statusVars[i] = *(pStatusVars[i]);
where pStatusVars contains addresses of several variables of the application. Addresses are legal, this has been verified by debugger.
When the line "dummy = 0" is compiled I get a sequence of NMI followed by ILLEGAL instruction trap. The NMIFLG register value, read inside the NMI handler, is 5, i.e.
bit C28FLUNCERR = 1 e NMIINT=1 (spruh22b pag. 194). After running the NMI handler the code runs into ITRAP and halts there (since I put an endless loop).
This happens when the code is run standalone from FLASH (I mean without debugger connected). If the code is run using a debugger which clears (set to zero) L1 RAM before launching the application itself, the traps disappear. If the L1 RAM-clearing instruction is removed from the debugger script, the trap are back again and can be reproduced in debug, confirming the sequence of NMI + ITRAP.
The C28 core is booted by M3 code calling IPCMtoCBootControlSystem(CBROM_MTOC_BOOTMODE_BOOT_FROM_FLASH); This function calls the RAMControlInitL0L3Ram, that should instruct the C28 BOOT ROM to clear the Lx RAM before launching the application, so I suppose that the L1 memory initialization for ECC correct usage is done, but something seems not working. Only "manually" clearing the L1 RAM appears to solve the problem (at least it is not immediately evident).
Besides that, if I comment out the "dummy = 0" line the code runs normally and everything seems working fine. In general, modifications of the code that are not actually related with the array involved in that loop may or may not let the trap happen. The code developed so far is rather long and mature and during development this problem popped out and disappeared randomly from time to time, as the code grew. I recently could check better and get the details above described.
The code also run into traps if I use the code written as:
for(i=0; i<STATUS_SIZE; i++)
dummy = getStatusValue(i);
(just for test) , i.e. writing the statusVars array is not the issue.
I suppose that there is some issue with ECC (something I miss or mistakenly done), but as stated above, the Lx memory clear for ECC should be correctly done by the M3 code during boot stage.
I'm using the latest release of Control Suite, just downloaded today.
Thanks in advance
Fabio