Migrating from KL03Z to KL03Z32VFG4

[dan2]

Hello!  I am new to working with the KL03Z and could use some tips.  Anything will help!

I have a program working on the KL03Z reference board and am trying to migrate to a custom board with the 16 pin KL03Z32VFG4.   I used the debugging trick mentioned in the ref board users guide (cut trace at J6 and hook to J7).  This has allowed offboard OpenSDA debugging.   I still get "Warning 17927. Target MCU mismatch.", even though I have changed the chip type in properties from KL03Z32VFK4 to VFG4.    However, the program seems to be debugging just fine (although a bit slower than the ref board).   The problem I have now is that when I call EnableIRQ() my program just hangs.  Forcing a break shows signal handler called at 0xfffffff9.   If I go back to the ref board, my code runs just fine.

I have found other similar posts in here where people have changed the processor.S file FOPT register to disable non maskable interrupts.   I did this (changed from default of 0x3F to 0x39, but this didn't change anything.   I'm not sure what might be happening here. 

Also, I found it strange that with the offboard chip, that it does not seem to be running my program when I apply power.

With the reference board, it always runs whatever program I debugged last on power up (even without KDS loaded)

This makes me wonder if the chip is even being flashed correctly?  It says "Programmed. Checksum Verification Successful."  I must be missing something here.  If I could at least program the device and run it without the debugger, I could determine whether my problem is in the code, or a side effect of trying to use the OpenSDA debugger built in to the ref board.

[jeremyzhou]

Hi Dan,

First of all, I'd highly recommend you to try again by following the procedure which is from the thread illustrates.

https://mcuoneclipse.com/2015/08/19/using-the-freescale-freedom-frdm-kl43z-to-debug-other-boards/

And you just feel free to contact with me if you have any further question about it.
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[dan2]

Ping, thanks for the response.  I double checked the procedure and it looks like I have done it right. 

I upgraded to Segger 2.1 OpenSDA to see if it would make a difference.   With the Segger OpenSDA, Its able to program and debug the KL03Z-FRDM just fine, but when I go to debug my external board I see the following:  1) chip gets loaded with new code and verification passes  2) halting of the chip works..  but 3)It won't stop on line 1 of main()     I force a break, but it goes into assembler.

This is different than what happened with the PE OpenSDA.   The PE OpenSDA ran slower, but it would at least get through a large portion of my code up until the point where I enabled the TMR0 IRQ.  

Is there a utility I can use to just force the HEX file down into my flash on the external board?   At this point, I'm more interested with whether it works or not than debugging.   I would assume the same object code should run in a KL03 whether I am using the 24 pin or the 16 provided that I have not used pins that don't exist for the 16 pin package and I have not.

[jeremyzhou]

Hi Dan,

I'd like to suggest that you can program the KL03 by using the ROM bootloader, and you can learn the more information about it through the link as below.

KBOOT learning diary
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[dan2]

Ping,   Thank you very much for the KBOOT link.  I did not have this info and it looks very useful. 

Update for everyone on the original issue.  We bought a multilink programmer thinking the FRDM debugging unit was the problem. 

But, as it turns out, it was not.  Our code compiles, downloads, verifies with both programmers through KDS, but it suffers from all kinds of strange issues while debugging.

We then built up a second circuit board with a new chip, and it works with BOTH the FRDM debugger and the multilink.

I suspect the microcontroller on the first board could be damaged somehow.  I wish the IDE could have detected that there was a problem somehow and saved us a lot of time, but you live and you learn I guess...