Cannot program the MKE04Z8

[gbm]

I am trying to program the MKE04Z8VTG4 (TSSOP16 variant) on our preproduction series boards with no succes). Basic facts are:

The board is pretty simple. To sort the problems out I assembled the boards without any components other than the microcontroller and decoupling & filter capacitors (100 nF +10 uF), placed very close to the chip.

The programmer is an FRDM/KL25Z board with SWDCLK jumper cut and wires soldered to my own SWD connector.

The programming cable is about 20 cm long.

I am using two different software/firmware combinations:

- Keil MDK/ARM + CMSIS_DAP firmware app

- USBDM ARM programmer + USBDM OpenSDA v2.1 firmware.

The first board programmed with no problems. I managed to program only 4 boards out of over 25 assembled.

After swapping the microcontrollers between the "good" and "bad" board, the uC from a "good" one can be programmed on a "bad" PCB and the "bad" uC cannot be programmed on a "good" PCB -> the problem should be attributed to the chip, NOT to the board.

The programming software correctly detects the chip and displays the message about erase failure (timeout). So no communication problems but rather an error in erase/program algorithm.

The chips are fresh and unused.

Tried two power supply configurations - 2.94 V from FRDM board or 3.3 V - same behavior.

Tried to lower the SWD clock frequency - no difference.

Any help will be appreciated.

[Paul_Tian]

Hi

My suggestion for you is you can add pull-up resistor on pin SWD-DIO on your 'bad' board and try again.

Best Regards

Paul

[gbm]

Did that already - 10 k pullup on SWDIO. No difference. I get "Flash erase timeout" message from 20+ chips that don't program, the other 4 programmed correctly.

The communication with the chips seems to be OK - the identifier is read correctly from all the chips.

[LuisCasado · Accepted solution]

Hello Mazur,

Check if the pin PTB4 (NMI) is at ‘low' level. Try to force to ‘high' and try again. Pemicro algorithm didn't disable NMI irq and old algorithms had that issue.

Best Regards,

Luis

[gbm]

That did the trick!

Actually I am using Keil MDK-ARM with CMSIS-DAP application programmed in FRDM board debug uC. My board has 10k pulldown on PTB4 (it's necessary for my hardware). After shorting PTB4 to Vdd the chip may be programmed - tried that on 4 boards so far.

Conclusions:

1. Programming script SHOULD disable NMI but it doesn't - PLEASE UPDATE the script/algorithm in Keil MKE pack!

2. I still don't understand why 4 micros out of 28 programmed without problems with PTB4 pulled down while the other 24 didn't.

Many thanks,

Gregory

[pgo]

Hi Gregorz,

You referred to USBDM at the top of this thread so I'll make some comments on your suggestions.

I wasn't aware of this issue until I saw this thread.  It may be the reason for some other similar issues.

I do not believe there is any alternative to tying the NMI pin high externally (or leaving it open as there is an internal pull-up).

The NMI is enabled out of power-on-reset.  The programmer would not necessarily have a chance to disable NMI if the pin was low so it would be quite possible for the target to lock-up before the debugger can get access.  It appears that the SOPT register is not accessible in reset.

Anyway I will look at adding this but it would not prevent all problems I think.  The only reason for not doing it with USBDM is that it becomes another device-specific action which is a pain.

bye