: "Illegal opcode happens the most often not due to selferased bits of flash, but due to uninitialized pointers, due to stack overflow etc."
: uninitialized pointers==> How ?Kindly can you explain this.I've heard this uninitialized pointers leads to crash.But never knew how?
If you try to access a part of the memory map where nothing resides, you will get an illegal opcode interrupt. If your pointers aren't initialized, they are pointing at a random location.
: due to stack overflow ==>Yes, If the program code resides in RAM (relocatable code-Flash routines) and gets overwritten then there is a case of illegal opcode issue.Is there any point which i missed to see?
When the stack overflows, you could get the same error as for unitialized pointers. The SP could then point at a non-valid memory location. Ie it has nothing to do with where the code resides, though code in RAM can cause further issues like the ones yoy mentioned.
If you are smart when you design your memory map, you put the stack on top of the RAM and make sure that the address above RAM isn't valid. If your program gets a stack overflow, you will then get the opcode interrupt + reset instead of the program starting to behave randomly. It will also be much easier to find stack error bugs using this method.
: @Lundin: "Another reason could be a corrupt binary file downloaded into the MCU from a PC, or that the download itself faced EMI. Hopefully, both binary files and download tools use checksums to check the data" .
S19 has checksum field as you said.Doesn't it protect from corrupt hex codes (in s19) being flashed into the MCU, even in case of EMI environment. No corrupt code enters from s19 point of view enters MCU;This is my understanding,Please correct me if I am wrong.
Then I will correct you
S19 is just an ASCII file which is the Motorola/Freescale standard way of storing programs on your PC. The BDM pod will read this file but translate it to raw binary data, which is then sent to the MCU.
First of all, the checksum in s-records is laughable. It just sums everything, there is a huge chance that such a checksum algorithm fails to detect file corruptions. The serious approach would have been to use CRC-8 or better. But no matter how good the checksum is, no checksum is 100% fail proof.
Second, what happens between the PC and the MCU is all in the hands of your BDM pod manufacturer. Hopefully they are using checksums/read-back, I have no idea.
: uninitialized pointers==> How ?Kindly can you explain this.I've heard this uninitialized pointers leads to crash.But never knew how?
If you try to access a part of the memory map where nothing resides, you will get an illegal opcode interrupt. If your pointers aren't initialized, they are pointing at a random location.
: due to stack overflow ==>Yes, If the program code resides in RAM (relocatable code-Flash routines) and gets overwritten then there is a case of illegal opcode issue.Is there any point which i missed to see?
When the stack overflows, you could get the same error as for unitialized pointers. The SP could then point at a non-valid memory location. Ie it has nothing to do with where the code resides, though code in RAM can cause further issues like the ones yoy mentioned.
If you are smart when you design your memory map, you put the stack on top of the RAM and make sure that the address above RAM isn't valid. If your program gets a stack overflow, you will then get the opcode interrupt + reset instead of the program starting to behave randomly. It will also be much easier to find stack error bugs using this method.
: @Lundin: "Another reason could be a corrupt binary file downloaded into the MCU from a PC, or that the download itself faced EMI. Hopefully, both binary files and download tools use checksums to check the data" .
S19 has checksum field as you said.Doesn't it protect from corrupt hex codes (in s19) being flashed into the MCU, even in case of EMI environment. No corrupt code enters from s19 point of view enters MCU;This is my understanding,Please correct me if I am wrong.
Then I will correct you
S19 is just an ASCII file which is the Motorola/Freescale standard way of storing programs on your PC. The BDM pod will read this file but translate it to raw binary data, which is then sent to the MCU.
First of all, the checksum in s-records is laughable. It just sums everything, there is a huge chance that such a checksum algorithm fails to detect file corruptions. The serious approach would have been to use CRC-8 or better. But no matter how good the checksum is, no checksum is 100% fail proof.
Second, what happens between the PC and the MCU is all in the hands of your BDM pod manufacturer. Hopefully they are using checksums/read-back, I have no idea.
WAR is taking place
@Mr Bean,
Stack return address taken from stack (RTS), with corrupt stack (under-/overflow, mismatch).
Messed up jump addresses from a table or something like that.
RTS(Surely calling function will put PC there in stack but maximum damage would be of stack overwritten in case of overflow.Underflow case doesn't appear in this case) and corrupt stack (under-/overflow, mismatch) both will never happen.And hence Unintentional execution is not possible..Only illegal opcode sometime later.Some time later = Only God knows
@Lundin: "If you try to access a part of the memory map where nothing resides, you will get an illegal opcode interrupt. I didn't see any documentation regarding this.Can you specify in datasheet plz.
If your pointers aren't initialized, they are pointing at a random location.
Nexus
oesn't Linker allote memory location for uninitialised pointers?Which Compiler are you using?
: due to stack overflow ==>Yes, If the program code resides in RAM (relocatable code-Flash routines) and gets overwritten then there is a case of illegal opcode issue.Is there any point which i missed to see?
When the stack overflows, you could get the same error as for unitialized pointers.
oesn't Linker allote memory location for uninitialised pointers?Which Compiler are you using?: due to stack overflow ==>Yes, If the program code resides in RAM (relocatable code-Flash routines) and gets overwritten then there is a case of illegal opcode issue.Is there any point which i missed to see?
When the stack overflows, you could get the same error as for unitialized pointers.
Nexus:I really doubt.It depends on where you initialised your SP.If your SP is initialised in Higher memory address area(Advised in datasheet),how illegal opcode reset can occur.It will continue to work creating havoc(it tries to run madly and finally fall to illegal opcode reset)
"The SP could then point at a non-valid memory location. Ie it has nothing to do with where the code resides, though code in RAM can cause further issues like the ones yoy mentioned."
Nexus:" I think you have initialised SP near lower RAM addr and above non-valid memory location is present.Its risky isn't it .How do you predict the stack space required in case your program needs it.
Message Edited by Geo*** on 2008-10-24 01:21 PM
Your question seems to be: Why do i need a watchdog or illegal opcode catching...Well, you are right that in a normal, correctly written & compiled program, no unintentional illegal opcodes, illegal addresses or watchdog resets will occur. None.
With the exception of extreme EMI or radiation strong enough to flip a bit (very very small chance under normal circumstances).
A good program doesnt hang.But, software writers do make mistakes. Compilers are written by software writers, also ... 
Watchdog and catching reset causes are there to be able to detect and catch these unfortunate mistakes.
Intentionally a C compiler allows to shoot yourself in the foot easilly:
eg. for a 908JB16, usefull for testing :
#define ILLEGAL_ADDR_FETCH_CRASH asm JMP 0x1000 // non existant address
#define ILLEGAL_OPCODE asm DCB #0xAC // illegal opcode
while(1); // watchdog reset
#define ILLEGAL_OPCODE asm DCB #0xAC // illegal opcode
while(1); // watchdog reset
Illegal opcodes can be generated in many ways.
The common cause is by unintentionally executing from RAM or other data-areas.
Illegal address access is also posible, accessing memory area that is non-existing.
The 2 above generate a reset (see ILOP & ILAD) by themselves, so there will be no "hang" + watchdog reset.
Look at the reset cause!
An easy way to hang the software and generate a watchdog reset is a loop that checks for a condition that does not occur.
DO NOT kick the watchdog from an interrupt routine !!
PS.: "IMO" is short for: "In My Opinion"
Message Edited by MrBean on 2008-10-24 11:13 AM
Hi MrBEAN
Thanks for your feedback.
Questions regarding occurance of HANG and generation of illegal opcode was seperate from my side, though they are sometimes interrelated.
I knew this
"The 2 above generate a reset (see ILOP & ILAD) by themselves, so there will be no "hang" + watchdog reset.
Look at the reset cause!"
"DO NOT kick the watchdog from an interrupt routine !!" You pointed out right.This surely is a GOLDEN rule for any WD design unless you want to disable it due to some unavoidable circumstances.
About illegal opcodes:"The common cause is by unintentionally executing from RAM or other data-areas." Did you mean stack overflow into relocatable code like flash routines ?Or anything else?
"An easy way to hang the software and generate a watchdog reset is a loop that checks for a condition that does not occur." Why should someone check for a condition that never occurs?Should be caught at the time of reviews.
Finally I'm not frustrating you guys.Please understand me.I'm trying to get deep into the problem
Checking, in a loop, for a condition that does not occur before a watchdog timeout is better said.
A stack over- or underflow could be the cause of runnning into a wrong memory area, yes, but also other causes could be.
If you could be more specific about the problem it would be easier to help.
Hi MrBean,
"Checking, in a loop, for a condition that does not occur before a watchdog timeout is better said". OK.Its going to happen but not before timeout,right! BAD DESIGN!!!
Sorry Bean,
My question was very generic,not specific to any controller,but applies to all controllers.
.Can you answer 5 and 8.
