Illegal Instruction in MCF5213

[cbhavi]

Hello,

I am using the Coldfire processor MCF5213 for a project and have been stuck with the Illegal Instruction exception for quite some time now.

On checking the stack frame I see that the address from wherein the exception occurs sometimes points to a FLASH address and sometimes to a RAM address (very inconsistent). The fault bits of the stack frame don't help either. (The value of the fault bits is 0b0000 and the reference manual of the device marks this as 'Reserved'.)

I went through the device errata for the processor and the description under "Internal Flash Speculation Address Qualification Incomplete" seems a likely cause to what I am looking at.

In the first page of the document there is a statement saying " All current MCF5211/12/13 devices are marked as M30B mask set." Does this mean that all the devices with the said mask set have the errata mentioned in the document corrected OR does the all the errata mentioned apply to the the particular mask set? I currently have the device with the M30B mask set.

I want to confirm this before I try implementing one of the workarounds given in the document.

Link to the Errata for reference : http://cache.freescale.com/files/32bit/doc/errata/MCF5213DE.pdf?fsrch=1&WT_TYPE=Errata&WT_VENDOR=FRE...

Regards,

Bhavya

[TomE · Accepted solution]

: (The value of the fault bits is 0b0000 and the reference manual of the device marks this as 'Reserved'.)

Look closely at the paragraph before "Table 3-7. Fault Status Encodings". It says:

    There is a 4-bit fault status field, FS[3:0], at the top of the system stack.

    This field is defined for access and address errors only and written as

    zeros for all other exceptions.

So for an illegal instruction it should be zero, like you're seeing. So you CAN trust the stack frame.

In fact, try to decode further back on the stack frame than you're doing. You may see a consistent pattern that previous stack frames are the same, and it is only the "last frame" that seems to be random. That may help you zero in on the real cause. Examine all of the CPU registers. The Address Registers should contain pointers to the data structures that were last being accessed, and that might tell you which functions it was in.

> the exception occurs sometimes points to a FLASH address and

> sometimes to a RAM address (very inconsistent).

If you're getting illegal instructions from RAM then ... I was going to say it is unlikely to be that Errata item as that should only affect FLASH fetches, but then I realised you're probably not executing from RAM and the CPU is probably going "off the rails" long before the access that caused the trap you're seeing. A CPU can "bounce around" randomly for a long time before it does something truly illegal and finally stops.

Before suspecting the CPU, it might be a software bug. The usual cause is stack corruption causing the CPU to return somewhere stupid when it does an interrupt or function return.

Workaround One is easy to implement. I'd do that first. You only have to set FLASHBAR[6] to "1". You may even be able to set this from the debugger. If you set that and the problem goes away, you've proved what the problem is. If the problem remains, start looking for software bugs corrupting the stack.

Tom

[cbhavi]

Thank you Tom.

I implemented Workaround-1 and the system seems to be running fine for now. I want to keep it going for a longer time to make sure the behavior previously was not due to any other software bug.