OpenSDAv2 firmware for custom K20+MKL25 board procedure?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

OpenSDAv2 firmware for custom K20+MKL25 board procedure?

Jump to solution
3,634 Views
demosdoumenis
Contributor II

Dear all,

We (www.quantimetrica.com) have developed a custom board with the following:

Programmer (USB HOST): Freescale K20Z128VFM4 microcontroller

Target : Freescale MKL25Z128VFM4 microcontroller

It is programmaticaly a variant of the FRDM-KL25Z board but since we cannot get our hands on K20 chips with built-in OpenSDA V1 from PEMicro, we had to use OpenSDAv2

We are open to other similar solutions (if any).

We try to debug/program the target chip from our host without success (only directly using a spare FRDM-KL25Z board or other SWD programmer).

We have installed CMSIS-DAP firmware with mbed (from Github repository) and installed all the necessary windows drivers (serial port, MSD, etc). We see target and host in the Keil environment

but when we try to debug/program/erase the target chip we get RDDI-DAP error.

How can one make a custom firmware for the K20 so that it can program the KL25 using all the standard (and excellent!) Freescale tools (e.g. CW, KDS etc) that the FRDM-KL24Z uses

According to CMSIS_DAP Interface Firmware one needs to create a bootloader+flash algorithm and combine the two into a single firmware file.

Any application note for doing this?

Thank you very much in advance,

Demos

1 Solution
2,173 Views
demosdoumenis
Contributor II

Hello Anthony,

We have been looking closely at your very concise instructions and we could only "see" processors using the JLink v2 (not v2.1) app. Using an FRDM-K20D50M as a host, our own K20 MCU can be recognised. However the same K20 MCU as host cannot recognise our own KL25 MCU on the same custom board. We did a lot of tests to identify the behaviour (hence the delay in responding) and the SDA_DATA signal going from our host to our target was always held high ('1'), even though the SDA_DATA was OK. On closer inspection there was a short circuit on our SDA_DATA line buffer between input and output. Fixing this on the board, all functionality was restored. Our board can now be programmed using KDS, or CW.

Cannot thank you enough as following your detailed instructions we could identify the hardware bug.

P.S. This issue can be considered closed.

Best regards,

Demos

View solution in original post

0 Kudos
16 Replies
2,173 Views
Carlos_Mendoza
NXP Employee
NXP Employee

Hi Demos,

I think that the following posts created by our colleague Erich Styger might be helpful for you, on this posts he explains how to create an open source ARM SWD debug board:

Proof of Concept: Open Source ARM SWD Debug and General Purpose Board | MCU on Eclipse

tinyK20 Open Source ARM Debug/Universal Board – First Prototypes | MCU on Eclipse

Regarding the RDDI-DAP error, make sure that on the debug properties the SWD option is selected instead of the JTAG option:

RDDI-DAP error by keil uVision and CMSIS DAP - Question | mbed

Best Regards,

Carlos Mendoza

Technical Support Engineer

-----------------------------------------------------------------------------------------------------------------------

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

-----------------------------------------------------------------------------------------------------------------------

0 Kudos
2,173 Views
demosdoumenis
Contributor II

Hello Carlos,

Thank you for your answer. I have studied the documents you sent over the past few days and it is reassuring that you also pointed out these documents.

We are using an FRDM-KL25Z board as a Segger J-Link (SEGGER - The Embedded Experts - OpenSDA / OpenSDA V2 ) to download code to our custom board which works great. The steps are as follows:

The tools such as Freescale Kinetis Design Studio cannot connect to the newly flashed board, could it be that one of the files (especially the debug app on the 3rd bullet) is wrong? Could you send me a set of working files if possible?

Thank you so much for your help,

P.S. we have the K20 QFN32 host and KL25 QFN32 target, both with 128K Flash.

Best regards,

Demos

0 Kudos
2,173 Views
Carlos_Mendoza
NXP Employee
NXP Employee

Hi Demos,

Could you send me the generated file k20dx128_kl25z_if_mbed.bin so I can test it on my side?

Also, have you tried using the Segger J-Link OpenSDA V2 app instead of the CMSIS-DAP app?

Hope it helps!

Best Regards,

Carlos Mendoza

Technical Support Engineer

0 Kudos
2,173 Views
demosdoumenis
Contributor II

Hello Carlos,

I have put the downloaded .axf file and our compiled .bin here. I hope this helps. It must be a simple mistake that we cannot see.

We are currently using an FRDM-KL25Z board as a .hex downloader to our target board (via SWD) until our own programmer works.

We use the FRDM-KL25Z board as a J-Link programmer (here) to program the .axf file to our host,

Remember our chips are:

Host: FREESCALE SEMICONDUCTOR  MK20DX128VFM5  MCU, 32BIT, CORTEX-M4, 50MHZ, QFN-32

Target: FREESCALE SEMICONDUCTOR  MKL25Z128VFM4  MCU, 32BIT, CORTEX-M0+, 48MHZ, QFN-32

Thanks a lot and best regards,

Demos

0 Kudos
2,173 Views
demosdoumenis
Contributor II

To possibly help further, there is an id for the target which seems wrong. When the debugger recognises the target a transfer byte routine should return 0x02, but in our case returns 0x07. Is this some kind of lock that does not enable the process to complete.

Thanks again,

Demos

0 Kudos
2,173 Views
Carlos_Mendoza
NXP Employee
NXP Employee

Hi Demos,

Thanks for the information.

I have done some tests using the k20dx128_kl25z_if_mbed.bin file and it is working correctly on my side, I tested it on KDS 3.0.0 using the K20DX128 MCU on the FRDM-K64F board to program and debug the KL25Z128 MCU on the TWR-KL25Z48M board.

Once I load the k20dx128_kl25z_if_mbed.bin file to the K20DX128 MCU it is correctly recognized by the computer:

pastedImage_0.png

And I'm able to flash and debug the KL25Z128 MCU:

pastedImage_1.png

My guess is that there might be something wrong with the board? can you post your schematics so I can review them?

Hope it helps!

Best Regards,

Carlos Mendoza

Technical Support Engineer

0 Kudos
2,173 Views
demosdoumenis
Contributor II

Hello Carlos and thank you so much for the comprehensive response!

I also can "see" both the host and the target chips on Keil uvision under the CMSIS-DAP debugger, so the files and the card must be OK. My board can enter "bootloader" mode with the reset button presses, otherwise it appears as "mbed" with an mbed serial port present.

I could think of the following "problem" which explains why the files work on the FRDM-K64F and TWR-KL25Z48M. Is there some kind of lock that allows genuine Freescale boards to work, but rejects user developped ones?

See below:

Same applies to KEIL that recognizes target but refuses to program or enter debug mode .

We suspect some sort of special permission as we checked

file board.c. It  seem to ask a BOARD_ID and BOARD_SECRET for our custom hardware as the code produces an error message

/* Each board should have a unique ID and secret. For information
*    about obtaining a secret contact support@mbed.org
*/

#include "board.h"
/* Each board should have a unique ID and secret. For information
* about obtaining a secret contact support@mbed.org
*/
#if defined (BOARD_FRDM_KL25Z) || defined (BOARD_TWR_KL25Z48M)
#define BOARD_ID   "0200"
#define BOARD_SECRET   "xxxxxxxx"
#elif defined (BOARD_FRDM_KL05Z)
#define BOARD_ID   "0210"
#define BOARD_SECRET   "xxxxxxxx"

Could this explain things?

Thank you again and best regards,

Demos

0 Kudos
2,174 Views
demosdoumenis
Contributor II

Under Freescale KDS the OpenOCD terminates with the following error (under windows 7 64-bit)

error1.jpg

0 Kudos
2,174 Views
UK_CF_FAE
NXP Employee
NXP Employee

That 'The system tried to join a drive....' error message can come from there being no console allocated to OpenOCD. Do you have it checked in your Debug Configuration? This is KDS 3.0.0:

pastedImage_0.png

It seemed to work OK for Carlos, and so I believe that the binary image you've created is correct. It must be something connected with the OpenOCD configuration on your PC, or the settings in KDS. Actually, since you have similar behaviour in KDS and from the command line, it is more likely to be OpenOCD settings.

Do you get the same behaviour on another PC?

Erich has a few tips on OpenOCD debugging here:

GDB Debugging with Kinetis Design Studio

0 Kudos
2,174 Views
demosdoumenis
Contributor II

Hello Mark,

Thanks for your detailed reply. I have been testing KDS on different PCs (and a Mac) with no success.

If you are sure it is an installation problem I might try re-installing everything.

Incidentally, the "Allocate concole for OpenOCD" tickbox is greyed and ticked, so I cannot change it on KDS 3.0.0

Really strange,

Best regards

Demos

0 Kudos
2,174 Views
anthony_huereca
NXP Employee
NXP Employee

One thing to try if you haven't already is to load the JLink for OpenSDAv2.1 app on the board and then connect via the JLink debug configuration in KDS instead of OpenOCD. You can find the JLink app at the bottom of:

https://www.segger.com/opensda.html

Make sure you install the driver also found on that page and it enumerates as a JLink then and as a virtual serial port. There is no lockout though with MBED/CMSIS-DAP firmware so I don't think that's the cause of the problem.

I'm also wondering if maybe there's a hardware issue in the connection between the K20 and the KL25? Did you make any modifications to the OpenSDA circuit on your board?

0 Kudos
2,173 Views
demosdoumenis
Contributor II

Hello Anthony,

Due to this firmware problem, we are indeed using an FRDM-KL25Z with the SEGGER JLink app to act as a programmer connected via a 10-pin SWD flat cable to our target board. The FRDM-KL25Z enumerates perfectly (see pictures) under JLink Configurator and KEIL (with J11 shorted, seeing its on-board KL25 chip)

pastedImage_0.pngpastedImage_1.png

However, when the same firmware is loaded on our custom board, it does not get recognised (see below).

pastedImage_2.png

but the FRDM-KL25Z connected via a flat cable to our board is recognised (see below, J11 open-circuited, seeing our custom board programmer chip) and we can flash the .axf file mentioned in OpenSDAv2

pastedImage_3.png

Our board as far as the OpenSDA circuit is concerned, is a direct replica of the FRDM-KL25Z.

Any ideas?

Thanks again,

Demos

0 Kudos
2,173 Views
anthony_huereca
NXP Employee
NXP Employee

Hi Demos,

I find it interesting your custom board K20 isn't being recognized as a JLink with the JLink app, but it enumerates as an MBED app. Maybe try dragging and dropping the JLink OpenSDAv2.0 app​ into the BOOTLOADER drive instead and see if that one comes up.

Also you could try the following for loading OpenSDAv2.1:

1) Erase and then load the attached bootloader binary (OpenSDAv2.1) onto the K20 device on your custom board

2) Plug in your board and make sure it comes up as BOOTLOADER drive

3) Drag-and-drop the K22F CMSIS-DAP app into that BOOTLOADER drive (this app will debug with any device, not just K22. The MSD drag-and-drop flashing is the K22 specific part)

4) Make sure it now comes up as MBED drive

5) Try debugging with the OpenOCD configuration

6) If debugging fails, let's try the JLink app

7) Go back into Bootloader mode (hold reset while plugging in board) and into the BOOTLOADER drive that should come up, drop in the JLink OpenSDAv2.1 app

8) Unplug and plug back in your board, and look in the Device Manager to make sure you have a JLink device and COM port

9) Try debugging with a JLink configuration

Hopefully one of those will work for you. If it doesn't, let me know what step failed.

-Anthony

0 Kudos
2,174 Views
demosdoumenis
Contributor II

Hello Anthony,

We have been looking closely at your very concise instructions and we could only "see" processors using the JLink v2 (not v2.1) app. Using an FRDM-K20D50M as a host, our own K20 MCU can be recognised. However the same K20 MCU as host cannot recognise our own KL25 MCU on the same custom board. We did a lot of tests to identify the behaviour (hence the delay in responding) and the SDA_DATA signal going from our host to our target was always held high ('1'), even though the SDA_DATA was OK. On closer inspection there was a short circuit on our SDA_DATA line buffer between input and output. Fixing this on the board, all functionality was restored. Our board can now be programmed using KDS, or CW.

Cannot thank you enough as following your detailed instructions we could identify the hardware bug.

P.S. This issue can be considered closed.

Best regards,

Demos

0 Kudos
2,173 Views
BlackNight
NXP Employee
NXP Employee

Yes, it is not possible to deallocate that option in OpenOCD (and I don't know why).

And related to that custom K20 OpenSDA: I'm right now in the process to port the mbed open source bootloader (which is on the K20 e.g. on the FRDM-K64F board) to GNU ARM GCC and Eclipse (KDS v3.0.0). Making progress, but not done yet.

See tinyK20: New Board with micro-SD Card | MCU on Eclipse  the background for that project, maybe this is of interest for you?

Erich

0 Kudos
2,173 Views
demosdoumenis
Contributor II

A combined bootloader+flash algorithm .axf file for Keil uVision would be great!

0 Kudos