software loss when runnng on car

[wangjiajie]

Hellow,everyone ,I meet a  emergency problem   when use MC9S12ZVCA192 chip,

the prombem did not occor in the lab ,but when on car it happened. and happend two times on road car  testing

after power off and on,the chip can't init   like the program itself is broken ,not running and have no functions .

first time the chip don't have bootloader and broken in 20000m,

second time the chip have bootloader and broken in 1000m,

I used BDM for the second time to access the BKGD pin and connected corretly ,and the memory data is mess.

Are there any Guide and Suggestions for this problem?

[kef2]

Hi,

Regarding code verify. CW Eclipse is so complicated and not intuitive, it's not clear for me how to verify code in MCU without erasing. I'm able, but it is so easy to fail to not erase, so |'d rather not provide you with my findings.. Sorry, perhaps someone else can help you how to verify code without erase.

Yes, MMCECH == 0x13 is EEPROM ECC exception. I'm not familiar with Freemaster. Does it read memory over BKGD without any assistance from firmware in MCU, right? If so, then it must be machine exception issue. You need to handle it.

Don't forget to verify your EEPROM ECC exception recovery really works. It can be initiated writing different data to the same location without erase. Not every data will trigger double error, I found some pattern easily. If you have problem with, this may help

https://community.nxp.com/docs/DOC-334381

Regards

Edward

[wangjiajie]

Freemaster can use the BKGD(BDM) to access the data

[kef2]

Hi  jiajie,

Wasn't your chip secured? I mean did you really connect over BDM correctly and saw real memory and not some pattern, which you would see reading secured MCU?

In case flash memory is OK, I guess you are using on-chip EEPROM, aren't you? S12ZVC has following feature listed in datasheet:

• Triggers S12ZCPU machine exceptions upon detection of illegal memory accesses and

uncorrectable ECC errors

How do you handle machine exception? Machine exception is triggered not only on RAM ECC failure or flash ECC failure, which should be fine for average application, but also on EEPROM ECC failure. It's possible but not easy to recover from machine exception, it's not like interrupt, from which you could simply exit, it doesn't do any changes to stack pointer, return address is lost. The problem is, if your MCU writes some data to EEPROM partially, for example due to power loss, or programming without erasing first, then reading it (which probably happens at each power on!) you are likely to get machine exception... If you simply reboot on machine exception, then you will enter it again and again reading the same piece of EEPROM with broken ECC... IMO it's very important to handle machine exception properly, perhaps erase affected EEPROM or initialize it to some factory default settings, certainly something should be done for reliable operation.

Regards,

Edward

[wangjiajie]

the mcu did not use the secure featrue, i used the freemaster tool to read the mcu data after i download the program by codeworrior "debug" button and do power off to reset the mcu.

i used eeprom function generated by processor expert to modify the eeprom and then i read back the data to check whether the data is writed success,

is this operation dangerous ? the power system in the car is not stable and there maybe some low power case when in road running test.

and how to handle machine exception? is this handle by the.processoer expert settings CPU-Events-OnMachineException ?

if the eeprom ecc triggers a machine exception ,how to solve the eeprom uncorrect data to prevent it from eeprom endless machine exception loop?

i also see.that there is a OnSRAM_ECCerrer events settings in the CompomentInspecter Cpu ,can this also help?

[kef2]

Hi,

• the mcu did not use the secure featrue, i used the freemaster tool to read the mcu data after i download the program by codeworrior "debug" button and do power off to reset the mcu.

As I understand, you didn’t verify that program code is as you left it, you only verified that in Freemaster you see wrong data. This is expected if code stuck somewhere.

It would be nice to verify if code in flash isn’t modified. I don’t know yet how to do it with Eclipse version of CW, I’ll try latter and let you know after I figure the way how to do it without code reflashing. I hope you didn’t erase or reflash bad unit yet?

i used eeprom function generated by processor expert to modify the eeprom and then i read back the data to check whether the data is writed success,

Well, read to verify write was OK isn’t bad thing. But, if MCU is left powered from start to the end of EEPROM programming, the nothing wrong is likely to happen to EEPROM ECC. Problem may arise if MCU is powered down in the middle of EEPROM operation.

and how to handle machine exception? is this handle by the.processoer expert settings CPU-Events-OnMachineException ?

(I’m not using Processor Expert. It always pays to deep study MCU features, and once done code generator like PE IMO just adds an extra level of complication, also the question arises how I’ll move to MCU, which is not supported by PE...) I tried creating project with PE, yes it’s OnMachineException. By default, in case ME handler is not defined, ME vector in PE generated vectors.c points to empty interrupt handler! This is obvious PE bug. Since ME doesn’t stack registers on exception, code will run into the weeds... By default it should be routine with for(;;) loop inside.

if the eeprom ecc triggers a machine exception ,how to solve the eeprom uncorrect data to prevent it from eeprom endless machine exception loop?

i also see.that there is a OnSRAM_ECCerrer events settings in the CompomentInspecter Cpu ,can this also help?

SRAM ECC has nothing to do with EEPROM ECC. Oh, if there would be registers, which pointed to address with bad ECC! It could be also some EEPROM check ECC command. Here it was discussed a bit:

https://community.nxp.com/thread/453862?sr=stream&ru=214565

You could handle it like this: Prior to reading any EEPROM address, you should register read address A in some global variable. Once ME happens, check bits in MMCECH registers to verify if exception was caused by EEPROM ECC or something different. If it really was EEPROM, erase EEPROM sector at A. Then reset MCU using COP or any other means.

Regards,

Edward

[wangjiajie]

The second bad controller was kept the original broken state,

and i am planning to do some basic checks to see whether there are physical damages,and then try to read the mcu memorys and registers to see the MMCECH state.

(the first broken ecu which is not working ,come back to work after i do reprogramming the ecu without any other trying...,so the second one is precious to keep the state )

[wangjiajie]

180528Updated :
I checked the MMCECH(0x13) AND MMCECL(0x32) AND it is EEPROM UNCORRECT ECC ERROR when CPU LOAD data

SEE mmcech and mmcecl
And I am going to add machine exception handling and try to verify the method