Segger JLink for MQX RTOS in KSDK Project using KDS for the MK60DX256Zxxx10

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

Segger JLink for MQX RTOS in KSDK Project using KDS for the MK60DX256Zxxx10

929 Views
nickerb
Contributor I

Hmm, even though the path and everything was setup properly a restart seemed to solve it for the non-Z part (the Z part still is un KSDK-able, but that's okay for this particular PCB). 

 

Neat!  Now it seems to build and link fine.  Nice.

 

One more (final?) question:  I've hooked up my JTAG and I've switched the debugger options from SWD to JTAG.  I set a breakpoint in the i++ of the main loop in the main.c generated file. but it never seems to reach the main loop.  Rather, when I pause debugging, I seem to be stuck in the DefaultISR.

 

The startup looks pretty normal:

SEGGER J-Link GDB Server V4.92 Command Line Version

 

 

JLinkARM.dll V4.92 (DLL compiled Sep 30 2014 09:33:42)

 

 

-----GDB Server start settings-----

GDBInit file:                  none

GDB Server Listening port:     2331

SWO raw output listening port: 2332

Terminal I/O port:             2333

Accept remote connection:      localhost only

Generate logfile:              off

Verify download:               on

Init regs on start:            on

Silent mode:                   off

Single run mode:               on

Target connection timeout:     5 sec.

------J-Link related settings------

J-Link Host interface:         USB

J-Link script:                 none

J-Link settings file:          none

------Target related settings------

Target device:                 MK60DX256xxx10

Target interface:              JTAG

Target interface speed:        30kHz

Target endian:                 little

 

 

Connecting to J-Link...

J-Link is connected.

Firmware: J-Link Ultra Rev.1 compiled Dec  3 2013 14:27:53

Hardware: V1.00

S/N: 291200292

OEM: IAR

Checking target voltage...

Target voltage: 3.33 V

Listening on TCP/IP port 2331

Connecting to target...

J-Link found 1 JTAG device, Total IRLen = 4

JTAG ID: 0x4BA00477 (Cortex-M4)

Connected to target

Waiting for GDB connection...Connected to 127.0.0.1

Reading all registers

Read 4 bytes @ address 0x00000000 (Data = 0x20008000)

Target interface speed set to 30 kHz

Resetting target

Halting target CPU...

...Target halted (PC = 0x00000530)

R0 = 00000000, R1 = 00000000, R2 = 00000000, R3 = 00000000

R4 = 00000000, R5 = 00000000, R6 = 00000000, R7 = 00000000

R8 = 00000000, R9 = 00000000, R10= 00000000, R11= 00000000

R12= 00000000, R13= 20008000, MSP= 20008000, PSP= 00000000

R14(LR) = FFFFFFFF, R15(PC) = 00000530

XPSR 01000000, APSR 00000000, EPSR 01000000, IPSR 00000000

CFBP 00000000, CONTROL 00, FAULTMASK 00, BASEPRI 00, PRIMASK 00

Reading all registers

Select auto target interface speed (3847 kHz)

Flash breakpoints enabled

Semi-hosting enabled (VectorAddr = 0x08)

Semihosting I/O set to GDB Client

Read 4 bytes @ address 0x00000530 (Data = 0x480AB672)

Downloading 1024 bytes @ address 0x00000000 - Verified OK

Downloading 16 bytes @ address 0x00000400 - Verified OK

Downloading 2344 bytes @ address 0x00000410 - Verified OK

Downloading 4 bytes @ address 0x00000D38 - Verified OK

Downloading 4 bytes @ address 0x00000D3C - Verified OK

Downloading 672 bytes @ address 0x00000D40 - Verified OK

Read 4 bytes @ address 0x00000530 (Data = 0x480AB672)

Read 2 bytes @ address 0x0000061C (Data = 0xF248)

Read 2 bytes @ address 0x0000061E (Data = 0x23BC)

Read 2 bytes @ address 0x00000620 (Data = 0xF6C1)

Read 2 bytes @ address 0x00000622 (Data = 0x73FF)

Read 2 bytes @ address 0x0000061C (Data = 0xF248)

Read 2 bytes @ address 0x0000061C (Data = 0xF248)

Read 2 bytes @ address 0x0000061E (Data = 0x23BC)

Read 2 bytes @ address 0x00000620 (Data = 0xF6C1)

Read 2 bytes @ address 0x00000622 (Data = 0x73FF)

Read 2 bytes @ address 0x0000061C (Data = 0xF248)

Read 2 bytes @ address 0x0000061E (Data = 0x23BC)

Read 2 bytes @ address 0x00000620 (Data = 0xF6C1)

Read 2 bytes @ address 0x00000622 (Data = 0x73FF)

Read 2 bytes @ address 0x0000061C (Data = 0xF248)

Resetting target

Halting target CPU...

...Target halted (PC = 0x00000530)

R0 = 00000000, R1 = 00000000, R2 = 00000000, R3 = 00000000

R4 = 00000000, R5 = 00000000, R6 = 00000000, R7 = 00000000

R8 = 00000000, R9 = 00000000, R10= 00000000, R11= 00000000

R12= 00000000, R13= 20008000, MSP= 20008000, PSP= 00000000

R14(LR) = FFFFFFFF, R15(PC) = 00000530

XPSR 01000000, APSR 00000000, EPSR 01000000, IPSR 00000000

CFBP 00000000, CONTROL 00, FAULTMASK 00, BASEPRI 00, PRIMASK 00

Reading all registers

Read 4 bytes @ address 0x00000530 (Data = 0x480AB672)

Setting breakpoint @ address 0x0000061C, Size = 2, BPHandle = 0x0002

Starting target CPU...

 

 

However, it runs without encounter the breakpoint.  When I pause, I seem to be at the unconditional branch into DefaultISR (line 362 of startup_MK60D10.S) and single stepping from here produces a loop of:

 

Performing single step...

...Target halted (PC = 0x00000568)

Reading all registers

Performing single step...

...Target halted (PC = 0x00000568)

Reading all registers

Performing single step...

...Target halted (PC = 0x00000568)

Reading all registers

Performing single step.

etc.

 

Is this an issue with our using a custom PCB that will be fixed with a properly custom BSP or am I just missing something obvious (which wouldn't surprise me at this point).

 

Thanks!

Labels (1)
0 Kudos
4 Replies

386 Views
DavidS
NXP Employee
NXP Employee

Hi Nick,

I branched this to a new thread.

Do you have a Tower TWR-K60D100M to test with?  If yes use one of the KSDK_1.1.0/demo projects that has a preconfigured GDB Segger J-Link Debugging setting to ensure hardware is working correctly.

NOTE: Only small tweak is to disable the Startup->Enable SWO setting (i.e. uncheck it).

Then test using it with your hardware.  If successful.....great!  If not, then best to compare your schematic to the TWR-K60D100M schematic.

Another suggestion is to setup the debugger to debug from the first instruction rather than main.  Since the hardware could be configured differently the code might be causing the exception you are seeing.  So stepping through the code will help find the offending instruction/function/setting. 

Just do not step through disable watchdog code as the instruction sequence is time sensitive so you must let it run full speed.

Regards,

David

0 Kudos

386 Views
nickerb
Contributor I

Sounds good!

We don't have a TWR-K60D100M around, just the chips in our custom PCB.  I don't mind comparing pinouts and vector table stuff if that's the best option with respect to debugging from here on out.  The SWO box is greyed out, as I'm using a JTAG interface rather than SWD.

0 Kudos

386 Views
Jorge_Gonzalez
NXP Employee
NXP Employee

Hello nick:

As David indicated in your other post, the K60D parts with a 'Z' are Revision 1. There are many differences between Rev 1.x and Rev 2.x, the details are in application note AN4445.

The current KSDK is not compatible with your device, only with Rev 2 K60D as the one in TWR-K60D100M. Before you run into a number of issues and annoying problems like the one you report above, I recommend you to suspend KSDK usage until you order some Rev 2.x parts.

If you have to stick to your Rev 1.x parts, there used to be a sample code package (No SDK), but it was removed from our website. If you are interested please submit a service request and I can send it to you: Sales and Support|Freescale


Regards!,
Jorge Gonzalez

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

0 Kudos

386 Views
nickerb
Contributor I

Thanks!  I've written a header file that adds compatibility for the Z part (as we absolutely must support the current Z boards we have in the field--even if this requires extra KDS configuration on our part).  This is all well and good for our IAR implementation of MQX, but now that we're trying to move to KDS // KSDK and using gcc to compile rather than IAR and the MQX implementation seems a bit different.

That is, we are using raw MQX 4.1.0 source in our current product.  The BSPs in our version are in mqx/mqx/source/bsp/*board*/<bsp file locations>.  The new MQX version (4.1.2? 5.0.1? Freescale MQX™ RTOS for Kinetis SDK 1.1.0 Release Notes (MQXKSDK110RN Rev 0) gives me somewhat conflicting information) has generic BSPs (as in, non-board specific) in Freescale/KSDK_1.1.0/rtos/mqx/mqx/source/bsp/<bsp files here>.  Is there a document somewhere that states how to port my old MQX project into a KSDK version so I can take advantage of KDS?  How exactly do I forward port this stuff?

Thanks

Nick

0 Kudos