Fill with NOP

Thank you Mark!

It looks like the default options are what I need, fill with 0s and NOPs.

Regards,

Monica

Hi again!

After reading more about it, I understood that a good practice is to fill the unused memory with NOPs followed by jumps to a known place in the program (like reset routine) or to fill it with SWI. 

<< If the CPU ever runs away, a convenient way to help get it back on track is to fill unused memory with a single byte instruction. Use either a SWI (software Interrupt) or a NOP (no operation) instruction followed by an occasional JSR Start instruction. >>

How can I do this? In the fields you've mentioned I can only write 16 or 32-bit values. What about instructions?

Thanks again,

Monica

Hi Monica,

The fill method used by the compiler and linker is only capable of 16 or 32-bit values as you mentioned, so the technique you described is not possible using the CCS fields.  I am not sure of the best way to go about implementing the technique you described.  You also need to be careful with jumping back to the start of the program after reaching unused memory locations since this behavior usually indicates some sort of fault and restarting the application may not be the best course of action.  Ultimately I would try to pick the one behavior I wanted if my program reached unfilled memory and use that instruction for filling all unused memory rather than doing a combination of NOPs and jump instructions to enable you to use the fill methods described above.

Hope this helps,

Mark-

There is a much simpler solution for this discussion.  A C2000 has 2 build in ITRAP instructions, ITRAP1 (0xFFFF) and ITRAP0 (0x0000). So if you fill all of the unused memory sections wit 0xFFFF (which btw, is the pattern of unused FLASH),  an ILLEGAL Instruction interrupt will be triggered, if the PC will point to such an address. The core will then start the ILLEGAL_ISR routine, where you can do whatever you want to do in such a situation. SPRU430e has all the details.

Thank you all for the answers!

Frank, that's really a great solution. I still can't find a way to return to the start of the code from the interrupt. I don't know yet if this is want will decide to do in the end or if this is a good practice.

After some settings, before leaving the interrupt I wrote:

asm(" B 7FF6h,UNC ");   

In .cmd I have:

 BEGIN       : origin = 0x3F7FF6, length = 0x000002

To test the interrupt, I force PC in the debugger to an unused memory address. Sometimes I get the indication on an LED that I got an interrupt, but I don't see the system restarting (should be seen on another LED), other times even if I force PC to the same address I don't get the interrupt. How could I test this? Is the code ok or I'm doing it totally wrong?

Thanks again,

Monica

Thank you for the solution, Frank! 

Monica,

The TMS320C28x CPU and Instruction Set Reference Guide is the SPRU430 document Frank is referencing.  Please refer to Section 3.6 Illegal-Instruction Trap for an introduction to the procedure Frank pointed out which also contains links to other sections of the Reference Guide.

Thank You and Best Regards,

Mark-

Monica,

The ITRAP ISR can aid in debugging how the illegal instruction was encountered.  Here is a Wiki article on the subject and here is another E2E forum discussion.  You can use the ISR as a breakpoint for discovering which memory location resulted in the ISR being called.  This post in particular shows how you can actually return from the IRS to the memory location causing the illegal instruction and hopefully aid you in debugging the problem with your code.  You may be overflowing your stack or exceeding the boundary of an array.  After reading some of your other posts the problem seems intermittent and delayed which is difficult to debug, but putting a breakpoint or using the ESTOP0 instruction to halt the CPU while debugging would allow you to halt the program once the error is reach and then use the aforementioned methods to hopefully figure out what is happening in your program.

One option if you really do just want to reset your device each time, which will not necessarily fix your issue or be a good long-term solution, would be to enable the Watchdog inside the ITRAP ISR and loop until the Watchdog triggers a reset.  This should automatically reset your device and allow you to restart your program.  Again, you may be able to discover what is actually causing these illegal instructions to occur and fix your program instead of having to reset your device!

Best of Luck,

Mark-

Thanks Mark!

I don't have an issue causing this illegal instruction. I just wanna implement a piece of code to handle this situation in case it appears. I'm trying to force an illegal instruction in the debugger, by changing the value in PC register and see what happens. The system does what I wrote in the ISR, but I want to get the execution back after something happens. So, I'm not trying to mask a problem in the code, just to take into account as many bad scenarios as I can think of.

I'll take a look to the link you've sent.

Regards,

Monica