We are using the MC9S08AW60 for quite some years now, and
recently we encounter problems with chips marked 5M75B:
Upon execution of an illegal opcode, the cpu seems to reset/restart
without the ILOP flag in the SRS register being set.
The system startup checks the ILOP and COP flags in order to decide
to either startup in bootloading or execute main program.
To fall back from main program and restart in bootloading mode the
main program intentionally executes a non defined opcode (0xD8) in order
to force a restart. The restart is performed, but the ILOP is not marked in the SRS register.
All former chips worked as intended, the ones with mensioned mask number do not.
Is this a known issue?
I am aware of the errata document and the issues to be expected,
Is it perhaps related to flash protection issues?
Thanks for any comment that could help me out.
I believe that I have the same question from one FEA in our system, anyway here are my comments
So the devise with the mask set 5M75B are set by the
opcode (0xD8) but the ILOP flag on the SRS register is not set, I understood correctly?
Answer your question
Is this a known issue? No
Is it perhaps related to flash protection issues? No do not think so, but do you have block protection enable? if not the errata SE133-FLASH does not applies.
Also this is no normal that if you cool the component and it became to work… can you explain a little bit. Also can you check if all the part has the same date code(the data code is the lane under the mask set on the body mark), can you please send me some picture of the failed devices?
I will wait for your comments
Have a good day.
Yes, the components do reset by ILOP (being 0x8D - I mistyped in my message) but when the SRS is read after restart, the ILOP flag is not set.
Yes part of the flash is block protected. NVPROT at adr 0xFFBD is set to 0xF8 and NVOPT at adr 0xFFBF is set to 0x82.
Temperature influence : faulty components will work when they are kept a bit cooler (e.g. not 20°C but 5°C). Opposite is also true. Some components work fine until the are heated to e.g. 60°C. This for me was the proof it is not software related.
I took some of yesterday's replacements session and inspected 22 components. These are the date codes :
18x XNGW1407; 2x XNYJ1246; 1x XNGX1407; 1x XNGR1320.
For me there's only one question pending : We bought 1500 new components at Farnell (short delivery times) with date code XNMZ1038. They seem to work fine. Do we have a risk of having the same issue?