Two dead S32K144 EVBs now

cancel
Showing results for 
Search instead for 
Did you mean: 

Two dead S32K144 EVBs now

589 Views
Contributor II

I've got two EVBs and both are now dead, unable to respond to either the JLink via JTAG or the OpenSDA on board. JLink reports that it cannot connect (and reads an invalid implementer code of 0x00 from CPUID). It looks like on both boards the chip is dead. The P&E debugger reports that the chip is secure and it should do a full erase, but I don't think that's really true. In any case, it doesn't bring the chip back.

I have been writing code to turn on SOSC and use the external crystal on the EVB. Could this have killed the chip in some way? I checked the schematics to see that it was an 8MHz crystal with the 1MOhm feedback resistor and should be driven with high gain. Is it possible that something is wrong here?

Tags (1)
0 Kudos
4 Replies

58 Views
NXP TechSupport
NXP TechSupport

Hi,

This has been disscussed a few time here on community, but we cannot reproduce this issue.

I know there is a similar problem on kinetis.

Please read this thread and document and let me know.

Thanks,

Regards,

Daniel

0 Kudos

58 Views
Contributor II

OK, I have found the problem.

It's the 16 magic flash bytes in the protection area of program flash: if these get set to the wrong values by mistake (burn the wrong .elf or .hex file, make a mistake in the linker definition, get the vector table sizing wrong, etc.) then the chip is bricked by the security / mass-erase fuses being blown. It's so easy to make such a mistake and the consequences are so huge that there needs to be a proper warning about this.

0 Kudos

58 Views
Contributor IV

By "magic flash bytes" I assume you're talking about the 0x400-0x410 range of flash? Good to know that screwing with that causes issues. 

0 Kudos

58 Views
Contributor II

Yep. They're copied to the actual protection registers on boot.

Someone else reported they bricked the chip by accidentally doing a block erase (rather than a sector erase) while executing from flash (which naturally causes a bus fault). So it seems if the flash erase process goes wrong somehow (maybe also a power fail to the JTAG probe?) it can leave those bytes in an indeterminate state, and then after a power/reset cycle no further mass erase can take place.

This is a very dangerous bit of the flash memory.

0 Kudos