usb-kw41z stuck in reset, can no longer program

benwillcocks · ‎04-22-2018

I seem to have got my usb-kw41z into a state where it no longer works. When I observe RST_TGTMCU_b, I see the attached waveform. I have checked the supply rail (P3V3_KW41) and it looks fine. When I drag and drop a new .bin file into DAPLINKBOOT, after a delay of about 45 secs, the file "FAIL.TXT" appears. This says "The transfer timed out".

From the waveform, I am guessing that every time (internal) reset is released, something happens which causes it to be re-asserted shortly afterwards. Is it possible that I have inadvertently programmed a flash location which causes this? If so, is there any way to undo it?

benwillcocks · ‎04-25-2018

I purchased the usw-kw41z as a platform for developing my own firmware, so I didn't try the example projects - I went straight to programming my own firmware into the kw41z using the kw41z SWD. Obviously I didn't expect my firmware to work first time... but I did expect that I would be able to keep reprogramming the kw41z as I debugged it! Once I had programmed the kw41z for the first time, I could no longer reprogram it via SWD, so I tried doing it via drag & drop into DAPLINKBOOT and that didn't work either. I tried some NXP example .bin files as well as my own. That's when I noticed the unexpected signal on the Nreset pin.

However, I have recently made some progress. It turns out I had made an error in my firmware build environment, so that the "flash configuration field" (0x400-0x40f) was getting programmed to 0xff. This has the effect of turning on security, locking out SWD debug after the next reset. I performed a mass erase, and once I had done that, I was able to program the kw41z via SWD and to get my firmware working. Interestingly, mass erase does not return the entire flash to 0xff as you might expect - location 0x40c gets set to 0xfe, and this is crucial as it turns off security.

It appears that the signal I observed on Nreset is not particularly unusual - I have found that simply mass erasing the flash (ie. putting the chip back to its factory state) causes the same periodic behaviour. The important thing I have realised is that the periodic behaviour on Nreset does not prevent the SWD from working - and once the flash is programmed with a valid application, Nreset behaves as you'd expect it to.

The only mystery that remains unsolved is that though I can now program the kw41z via its SWD, the DAPLINKBOOT drag-and-drop method still doesn't seem to work. Does this mean that DAPLINK can only reprogram the kw41z with some assistance from the firmware already in the kw41z? I had assumed it used the SWD, and could therefore program a blank kw41z?

diegocomin · ‎06-13-2018

Hi Ben,

I have the same reset problem with the attached waveform:

In my case when I try to debug I obtain the following image:

And I can not program my KW41Z module. I have not used a usb-kw41z, I have made a custom board with the kw41z. How did you solve this problem? Did you get the same debug error?

I am using McuExpresso and can not see the option you said "flash configuration field", how can i flash the module with this IDE?

Bests,

Diego C.

benwillcocks · ‎06-13-2018

Diego,

If your problem is the same as mine was, then you're looking for an option to mass erase the flash. If you search for "mass erase" in the MKW41Z reference manual you'll see what it does. I didn't use McuExpresso so I'm afraid I can't advise you how to do it with that tool.

Good luck!

Ben

diegocomin · ‎06-14-2018

Hi Ben,

It seems I have the same problem than you. I have taken a look at "mass erase" in the MKW41Z reference manual and I think all blank modules are in secure state by default. KW41Z can not be debuged at first via SWD (the debug port has no access to memory locations in secure mode), but we should be able to access to the CPU flash and the programmer interfaces are only allowed to launch mass erase operations.

I think you are the only guy that can help me with that problem. Can you tell me what tool did you use to perform a "mass erase" to the KW41Z module via SWD? What are the steps that did you take and the program you used to do it? Can you make some screenshots? I am using a J-Link tool to debug KW41Z via SWD.

I really appreaciate your help,

Bests,

Diego C.

benwillcocks · ‎06-14-2018

Diego,

Unfortunately I used "home brew" software to control the SWD interface via an FTDI TTL-232R_3V3 USB - serial cable. I had previously written production test software to program and control an Atmel SAM D20 via SWD, and it was quite easy to hack this to make it work with the KW41Z. I'm happy to give you the C source if you want it, but I can't offer to support it and I think you would be better off sticking with the NXP tools. Are you sure you can't do a mass erase using McuExpresso (or some other official NXP tool)?

Rgds,

Ben

miduo · ‎04-25-2018

Hi,

Please let me know did you just gotten your board and immediately plugged it to find this failure? Or did the board initially work, and then you programmed a project onto the board to find this failure? If the second one, can you be a little more specific as to which project you programmed onto the board and what file you were drag?