Bricked MKL05Z32 after programming with USBDM

[gzalo_com]

Hi everyone.

I'm having a weird issue with a MKL05Z32 microcontroller. I'm using a custom board with only the main components populated (decoupling cap near uC, 3.3v regulator + cap and 10 pin header). It worked fine a couple of times, but after progamming it with USBDM with a certain program, the security status turned into "secure", and it can't be mass erased anymore.

I've changed the chip only to find that the same thing happened again, first download worked but it was bricked after that :smileyalert: 

Using USBDM and checking the MDM Status, it seems that the microcontroller enters the mass erase stage, but it never clears the MASS_ERASE_ACK bit. It also seems like the FLASH_RDY bit gets set and cleared randomly :smileyalert:. So the mass erase process timeouts and fails.

I even tried using openocd with a raspberry pi to attempt to erase it, but the same thing is happening :smileysad:

I have the project in Dropbox, so I checked how the uploaded elf file changed after it started failing, and I've realised that it might have started failing after disabling NMI pin (setting FOPT register value in 0x40C with value 0xFB instead of 0xFF). The other bytes regarding security are the default (0x7E for FSEC, FF everyting else). But why would that interfere with the programming?

Could it be that somehow the security bits were written in a wrong order or something similar? I will discard this board and keep nmi just as it was, but I'd like to know what the real reason is...

Other causes were discarded, don't think it was ESD (the microcontroller was soldered with an antistatic strap with proper grounding), temperature (we only soldered the 3 swd pins ,1 for the LED and 4 supply pins).

Any ideas?

Many thanks,
Gonzalo

[pgo]

Hi Gonzalo,

Can you post the binary file that caused the problem and I will have  a look at what is happening when being programmed.

I tried programming a MKL05 with a test program that just flashed an LED.

It programmed correctly and I was able to verify it after programming so it was not secured.

For reference I read back the security area using USBDM memory dump program and the SREC confirmed the contents as follows:

S11304000001020304050607FFFFFFFF7EFBFFFF59‍‍‍

This confirmed FSEC=0x7E, NVOPT=0xFB similar to your case.

Did you have anything connected to the NMI pin on your board as this can affect programming if NMI is enabled?

bye

[gzalo_com]

Hi. Thanks!

After some destructive testing of the PCB, it seems like the ground trace that goes from the 10 pin connector and the microcontroller was cracked, and that could have caused an intermittent connection :smileysad:. The ground could have been supplied through the reset pin and the clamping diode... some part of the flash controller probably broke after that.

If you want to test it anyway, here you go: http://gzalo.com/downloads/1134Sensor.elf . I think that's the version that made the uC secure with no way to mass erase. I think it used the RTC with an external 32 KHz crystal, and attempted to blink a LED on the RTC_seconds ISR.

NMI was connected to something but it wasn't solderd yet. After the problem I've tried pulling it up/down with no results.

Gonzalo