Cannto debug Kinetis S9KEAZ128 - Mask set problem?

[tevfikbasaran]

Hi,

I'm trying to debug an S9KEAZ128AMLH with KDS 3.2.0 installed on windows 10 and Segger J-Link EDU but it looks like I'm stumbling on the mask set issues adressed in e6945 and e6946 erratas.

I'm working on a few of our in-house designed prototype boards. I checked all the SWD connections from Segger outputs to MCU inputs. All seem fine.

When I tried debugging the first time everything was working well. Flashing leds, reading inputs, timer interrupt etc. But after a few times of flashing the MCU I began to receive an error code that the debugger could not detect CPU clock speed.

I've been trying all solutions I could find in this forum. Tried updating drivers, re-installing all software, adding debugger commands as recommended here. Nothing works.

I read the erratas about mask sets 2N22J and 2N45K. We have two sets of S9KEAZ128 MCUs purchased at different times and they happen to belong to those mask sets.

The errata documents speak of a solution about setting up the debugger in certain ways to avoid MCU lockup but I don't know how to set up the debugger so well. Can't NXP release a debugger script to work around that error?

We need to get these boards running and we're far behind schedule. Please help.

Here is a log of my latest trial:

SEGGER J-Link GDB Server V5.10n Command Line Version

JLinkARM.dll V5.10n (DLL compiled Feb 19 2016 18:39:11)

-----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: 0 ms
------J-Link related settings------
J-Link Host interface: USB
J-Link script: none
J-Link settings file: none
------Target related settings------
Target device: SKEAZ128xxx4
Target interface: SWD
Target interface speed: 4000kHz
Target endian: little

Connecting to J-Link...
J-Link is connected.
Firmware: J-Link V9 compiled Jun 16 2017 16:15:10
Hardware: V9.30
S/N: 269305461
OEM: SEGGER-EDU
Feature(s): FlashBP, GDB
Checking target voltage...
Target voltage: 4.88 V
Listening on TCP/IP port 2331
Connecting to target...Connected to target
Waiting for GDB connection...Connected to 127.0.0.1
Reading all registers
Read 4 bytes @ address 0x00000000 (Data = 0xFFFFFFFF)
Target interface speed set to 1000 kHz
Resetting target
Halting target CPU...
...Target halted (PC = 0xFFFFFFFE)
R0 = 00820180, R1 = 02000401, R2 = 10000080, R3 = 00802080
R4 = 30110408, R5 = 04000A08, R6 = 80231008, R7 = 10126020
R8 = 25084000, R9 = 14020012, R10= 04000400, R11= 000E0004
R12= 00200000, R13= FFFFFFFC, MSP= FFFFFFFC, PSP= 00050040
R14(LR) = FFFFFFF9, R15(PC) = FFFFFFFE
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 (2000 kHz)
Flash breakpoints enabled
Semi-hosting enabled (Handle on BKPT)
Semihosting I/O set to TELNET Client
SWO disabled succesfully.
ERROR: Failed to preserve original RAM content before CPU clock frequency detection!
Failed to restore original RAM content after CPU clock frequency detection!

Failed to enable SWO. Could not measure target CPU frequency.
Writing 0x06 @ address 0x40064000
Writing 0x0000000C @ address 0x40048004
Downloading 192 bytes @ address 0x00000000 - Verified OK
Downloading 16 bytes @ address 0x00000400 - Verified OK
Downloading 2660 bytes @ address 0x00000410 - Verified OK
Downloading 8 bytes @ address 0x00000E74 - Verified OK
Downloading 4 bytes @ address 0x00000E7C - Verified OK
Downloading 4 bytes @ address 0x00000E80 - Verified OK
Downloading 96 bytes @ address 0x00000E84 - Verified OK
Downloading 24 bytes @ address 0x00000EE4 - Verified OK
ERROR: Failed to measure CPU clock frequency
Could not detect CPU clock speed. Download of test code into RAM failed.

Writing register (PC = 0x00000a4c)
Read 4 bytes @ address 0x00000A4C (Data = 0xFFFFFFFF)
Read 2 bytes @ address 0x000008C4 (Data = 0xFFFF)
Read 2 bytes @ address 0x000008C4 (Data = 0xFFFF)
Resetting target
Halting target CPU...
...Target halted (PC = 0xFFFFFFFE)
Read 2 bytes @ address 0x000008C4 (Data = 0xFFFF)
Read 2 bytes @ address 0x000008C4 (Data = 0xFFFF)
Read 2 bytes @ address 0x000008C4 (Data = 0xFFFF)
R0 = 00820180, R1 = 02000401, R2 = 10000080, R3 = 00802080
R4 = 30110408, R5 = 04000A08, R6 = 80231008, R7 = 10126020
R8 = 25084000, R9 = 14020012, R10= 04000400, R11= 000E0004
R12= 00200000, R13= FFFFFFFC, MSP= FFFFFFFC, PSP= 00050040
R14(LR) = FFFFFFF9, R15(PC) = FFFFFFFE
XPSR 01000000, APSR 00000000, EPSR 01000000, IPSR 00000000
CFBP 00000000, CONTROL 00, FAULTMASK 00, BASEPRI 00, PRIMASK 00
Reading all registers
WARNING: Failed to read memory @ address 0xFFFFFFFE
Setting breakpoint @ address 0x000008C4, Size = 2, BPHandle = 0x0001
Starting target CPU...
...Target halted (PC = 0xFFFFFFFE)
Reading all registers
Removing breakpoint @ address 0x000008C4, Size = 2
WARNING: Failed to read memory @ address 0xFFFFFFFE
WARNING: Failed to read memory @ address 0xFFFFFFF4
Reading 64 bytes @ address 0xFFFFFFC0
WARNING: Failed to read memory @ address 0xFFFFFFC0
Reading 64 bytes @ address 0xFFFFFFC0
WARNING: Failed to read memory @ address 0xFFFFFFC0

[Carlos_Mendoza · Accepted solution]

Hi Tevfik,

You can disable NMI functionality (if this is not used) by writing to SIM_SOPT[NMIE] field (write 0 to disable NMI) so you can avoid having the e6945 issue. You can write this value in linker section so this value will be loaded after Power-On Reset.

Regarding the errata e6946, halting the processor in Debug state before performing writes to the I/O port region of the memory map should work. From your log I see that you are already doing this.

Hope it helps!

Best Regards,
Carlos Mendoza
Technical Support Engineer

[tevfikbasaran]

Hi Carlos,

Thanks for the info.

It turned out that we had two sets MCUs for the proto boards we were working on nowadays. KEAZN64AMLH and KEAZ128AMLH. The board I was having trouble with had a KEAZ64 on it, but I was trying to debug it with KEAZ128 settings in Processor Expert!!

So I prepared two new proto boards with KEAZ128. I can flash and debug them now.

However, I also tried KEAZN64 MCUs on proto boards (this time with proper configuration) and all of the story above is there again. All our focus nowadays is on those KEAZ128 MCUs, so I won't spend time trying to debug KEAZ64. I may ask for help on that later again.

Tevfik Basaran

[Carlos_Mendoza]

Hi Tevfik,

You are welcome, it is good to hear you can flash and debug them now.

Best Regards,
Carlos Mendoza
Technical Support Engineer