USBDM 4.12.1 - MKE02Z16 - Programming failed

[danielhulshof]

Hello, I'm using the USBDM_SWD_SER_JS16CWJ board, firmware version 4.12.1.

I'm trying to program and debug a custom board with an MKE02Z16VLC4 uController.

The Flash Programmer tool can detect the chip correctly, and the "Mass Erase Now" works properly.

But when I try the "Program Flash" operation, I get the following error message:

"Programming of the target flash failed!

Reason: Flash command failed (Verify, Erase, Blank check or Program)".

I have tried all sorts of configurations and Security options, no success.

Any ideas what might be wrong?

Thanks a lot!

[pgo]

Hi Daniel,

As usual I do not have that particular chip to test with.  The nearest I have is a MKE02Z64VQH4 on  a FRDM-KE02Z40M board.

I can program that chip using an external JS16 based programmer or  the on-board OPENSDA programmer without any error.

The MKE02Z64VQH4 is described by the same manual as the one you are using so I would expect the programmer to perform the same (providing I have read the memory sizes correctly).

• Could you run the debug version of the programmer in the installation directory and post the log file in %APPDATA%\usbdm\Flashprogrammer.log  (under windows I assume??)
• Could you post the circuit of the board you are using?
• Could you post the actual file you are programming in case there is something unexpected triggering a bug?

bye

[danielhulshof]

Hi pgo,

Looking at the "Kinetis-KExx-flash-scripts.tcl" I noticed that the addresses to the "FTFL_*" registers are wrong (according to the KE02 Sub-Family Reference Manual) but as those are not used anywhere on the script I believe it's no harm.

Looking at the Flashprogrammer.log I could see that the execution of the "Kinetis-FTMRH-flash-program-gcc.hex" may have encountered some problem. After executing the first "OpProgram" operation, the PC had the value of 0xFFFFFFFE. It happens every time I try to program the chip.

Looking at the source code for the "Kinetis-FTMRH-flash-program-gcc.hex" I could not find anything really wrong with it, even though it's all new to me. The "FlashController" struct has all it's fields on the right order. The FCMD are all correct. The MCM_PLACR address and bits are correct. The WDOG addresses and bits are correct. The SIM_SOPT_NMIE bit should be "(1<<1)" instead of "(1<<2)", but as it's not used (line 245 on main.c commented), I don't think it's a problem.

I'll keep digging, and posting if anything comes up.

Thanks.

[pgo]

Hi Daniel,

The FTFL_BASE_ADDRESS that appears in the file is only used for testing with whatever chip I used initially - The actual address is passed to the code in the FlashData_t struct.  You can confirm the address in the (copious) log file.  Since the MKE02Z64VQH4 works and its the same manual it should also be correct for the MKE02Z16VLC4. 

The kinds of things I need to check are memory ranges and any differences between the chips.I have not been able to find any discrepancies!

bye

PS.  Could you retry with the latest version which has just been posted in case there is a difference I have missed - I have been testing with this version,

[danielhulshof]

Hi pgo,

I'm already using 4.12.1.50, and there was no difference.

Do you have any idea what could cause the PC to get to 0xFFFFFFFE?

And the error code of 0xFFFF, what does it mean?

As the KE02 family has no RCM, the values on SR0 and SR1 can be ignored right?

Thanks.

[pgo]

Hi Daniel,

The entry point to the flash programming routine downloaded to the target is here

usbdm-flash-routines/main.c at master · podonoghue/usbdm-flash-routines · GitHub

This does some initialization:

1. Sets Vector table base address
2. Disables the WDOG
3. Sets up the data to program
4. Clears the complete flag in the flashData->flags
5. Clears the raw error code in flashData->errorCode (the download sets this to 0xFFFF)

The fact that the raw error code is still 65535 indicates that it did not complete the above sequence.

This is further confirmed because none of the action flags are cleared.(DO_INIT_FLASH|DO_BLANK_CHECK_RANGE|DO_PROGRAM_RANGE|DO_VERIFY_RANGE|).

The log you provided indicates that the cpu is ending up at 0xFFFFFFFE.  This usually indicates the code crashed badly e.g.

trapped and loaded an invalid reset vector of something similar (since the chip would be blank the vector would be 0xFFFFFFFF).

I can't see anything wrong with this portion of code!

I can program a MKE02Z64VQH4  using the  MKE02Z16VLC4 device description so I'm stumped why it should fail for an actual MKE02Z16VLC4.

PS.

I have attached an updated DLL that should print out the srsid which might be of use.

[danielhulshof]

Hi pgo,

Hurray! Finally found the issue!!

Only now I saw the SRSID print modification you did!

It's all about the NMI input Pin, the damn thing!

My board uses the PTB4/NMI as an input pin, with an external pull down resistor, which causes the NMI to interrupt and lockup the core.

I've removed the pull down resistor and voila, it works!!

There are two things to do on the "Kinetis-FTMRH-flash-program-gcc" to fix this, I guess:

Here is the definition of the SIM_SOPT_NMIE field of the SIM_SOPT register. It's value should be (1<<1) as it is the BIT1 of the SIM_SOPT register.

Here is the commented line that disables the NMI Pin. It should be uncommented.

Could you generate a new .hex file with those fixes please?

I believe that with the NMI pin disabled I'll be able to program my board without having to modify anything on it.

Let's how it goes!

Thanks a lot!

[pgo]

Hi Daniel,

I previously did this but found that it interfered with debugging a program that used NMI.  It was also ineffective since the value is restored on reset i.e. the problem occurs before the flash programming code actually gets a chance to run.

I have attached the modified code for you to try but I suspect the proper place to do this would be in the tcl script.

I will have to test this further I think .

[pgo · Accepted solution]

Hi Daniel,

Followup:

As expected, trying the modified flash code did not work on the MKE02Z64VQH4  I have with the NMI pin tied low.

The attached tcl script did work BUT it disables the NMI until a power-cycle is done on the target.

As a compromise It only does this on mass erase.

This allows NMI code to be debugged if selective erase is chosen in the debugger i.e. in your case, you would change the option to mass erase if debugging.

Note: Once NMI is disabled it stays disabled until the next power-cycle which can be confusing.

This is a bit of a mess - I think the only sensible approach is to design the hardware so that NMI is not asserted at reset.  This is the only approach applicable to other devices which do not have an software accessible option to disable NMI.

bye

[danielhulshof]

Hi pgo,

This fix worked fine for me! I tried it with another board that had the pull down resistor on the NMI pin, and it worked perfectly.

As I already had "Mass erase" enabled at debug, it didn't change much of my operation.

Thinking about it, it seems to me that this is the proper way to work around the issue. The NMI has to be disabled right after a POR. According to the manual, "This pin defaults to NMI following an MCU POR. Other resets will not affect this bit.".

As I don't have another option (every available pin is being used!) I'll have to keep using the NMI input as PTB4.

But this is not an issue once the board is already programmed.

Thank you for all the effort on working this out! And congratulations for the great work you are doing!

[danielhulshof]

Hi pgo,

I've also looked at the source code for the flash routine, and couldn't find anything wrong with it.

So, my suspicion is now towards the "writeMemory(...)" operation that writes the flash routine to the target RAM.

If something goes wrong during this operation, some instructions could get messed up and ruin the whole flash routine.

I'll keep trying and posting here. If you think of anything that could help me, please share!

Thanks a lot!

[pgo]

Hi Daniel,

Attached is a further modified DLL.

If prints out the RAM contents on error.

I think it unlikely that the writing is failing but this will allow this to be checked.

bye

[danielhulshof]

Hi pgo,

Here is the only different address line (addr - print - hex):

0x1FFFFEE0 - BE00000000000000000000001C020020 - BE000000000000000000000000000000

I'm attaching the FlashProgrammer.log and my Kinetis-FTMRH-flash-program-gcc.hex file.

I'll run it a few more times to check if it shows any other difference.

Thanks.

[danielhulshof]

Hi pgo,

Here is all the requested information.

The circuit presented has a P2 connector, which I'm using to program the board.

The USBDM board seems to be able to communicate with the target board correctly, given the "Mass Erase Now" works. And also, it can identify the uController correctly as well.

I'm using the default project created with USBDM "New Project" wizard, which is a simple loop with counter.

Also, I've dumped the uC memory, with the option "Keep Empty SRECs", and tried to program it back but it didn't work either.

Thanks!