Kinetis EA Flashing?

[akohlsmith]

I've got a very simple Kinetis EA (S9KEAZN64AMLC) design. It's using the internal oscillator. I can build code for it using the Kinetis Design Studio, and my J-Link Lite can see it and talk to it. I can use the tools to read and write to SRAM.

I can't, however, flash the device.  I've tried both within the IDE as well as with the command line J-Link Commander tool. The devices are definitely not locked (fresh stock from DigiKey). OpenOCD doesn't have the correct flash algorithm for this specific series of Kinetis.

How does one flash these devices? I am sure I'm missing something stupid, and my gut tells me that it's perhaps the fact that I'm using the slow internal oscillator. I've not found anything useful on these forums or on various web searches, and I'm getting pretty frustrated. Can anyone shed some light on this? I'm running on a 3.3V regulated supply, I'm not doing anything goofy with any of the I/O, and the SWD interface is not being shared with anything else.

Sample output from JLinkExe:

$ JLinkExe

SEGGER J-Link Commander V4.94c ('?' for help)

Compiled Oct 31 2014 20:08:55

DLL version V4.94c, compiled Oct 31 2014 20:08:48

Firmware: J-Link Lite-Cortex-M V8 compiled Jul 17 2014 11:40:12

Hardware: V8.00

S/N: 518107921

Feature(s): GDB

VTarget = 3.332V

Info: Could not measure total IR len. TDO is constant high.

Info: Could not measure total IR len. TDO is constant high.

No devices found on JTAG chain. Trying to find device on SWD.

Info: Found SWD-DP with ID 0x0BC11477

Info: Found Cortex-M0 r0p0, Little endian.

Info: FPUnit: 2 code (BP) slots and 0 literal slots

Cortex-M0 identified.

Target interface speed: 100 kHz

J-Link>device skeazn64xxx2

Info: Device "SKEAZN64XXX2" selected (64 KB flash, 4 KB RAM).

Reconnecting to target...

Info: Found SWD-DP with ID 0x0BC11477

Info: Found SWD-DP with ID 0x0BC11477

Info: Found Cortex-M0 r0p0, Little endian.

Info: FPUnit: 2 code (BP) slots and 0 literal slots

J-Link>r

Reset delay: 0 ms

Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit.

J-Link>erase

Erasing device (SKEAZN64xxx2)...

(...several second pause while it communicates with the MCU...)

****** Error: PC of target system has unexpected value after erasing sector. (PC = 0xFFFFFFFE)!

---------------------------------------------------------------------- Registers -------------------------------------------------------------------------------------

    PC   = FFFFFFFE

Current: R0   = 00F3E3BE, R1   = 00000001, R2   = 4004801C, R3   = 00000001

    R4   = 00000000, R5   = 00000000, R6   = 000000F4, R7   = 1FFFFD61

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

Info: J-Link: Flash download: Total time needed: 2.174s (Prepare: 0.894s, Compare: 0.000s, Erase: 0.736s, Program: 0.000s, Verify: 0.000s, Restore: 0.542s)

ERROR: Erase returned with error code -5.

Dec 29 edit:

Some more information:

I read that the NMI# pin is enabled out of reset (and verified this by reading SIM_SOPT) but also that it has an internal pull-up when enabled. On this particular part PTB4 is on pin 10 which is a no-connect in my design. Disabling the NMI pin makes no difference.

Looking at clocking now... Out of reset, ICS is the clock source to the FLL and BDIV in ICS_C2 is set to 001 (the reset default). If I understand correctly, this means that the 32kHz internal oscillator is multiplied by 1024 by the FLL and then divided by 2, making ICSOUTCLK 32kHz * 1024 / 2 or 16.8MHz. I can verify through the J-Link CLI that the FLL is locked by reading ICS_S:

J-Link>mem8 40064004 1

40064004 = 50

(LOCK and IREFST are set, this is correct.)

I then move on to verify that the SIM has the clock enabled for the flash controller by reading SIM_SCGC. I can also quickly check to make sure that BUSDIV in SIM_BUSDIV is set to zero which means that the BUSCLK is the same frequency as ICSOUTCLK (i.e. it's not being divided down):

J-Link>mem32 4004800c 1

4004800C = 00003000

J-Link>mem32 40048018 1

40048018 = 00000000

So far, everything looks fine. BUSCLK is 16.8MHz and the flash controller clock isn't gated.

Now let's move on to the flash controller. Out of reset FCLKDIV is zero, and we need a 1MHz clock. Table 18-2 in KEA64RM shows that FDIV should be set to 0x10.

Out of reset:

J-Link>mem8 40020000 1

40020000 = 00

Setting up the divider and verifying things are good:

J-Link>w1 40020000 10

Writing 10 -> 40020000

J-Link>mem8 40020000 1

40020000 = 90

FDIVLD is set and the correct value in FDIV is shown.

Before going too far ahead, let's make sure that the flash isn't protected:

J-Link>mem8 40020001 1

40020001 = FE

KEYEN = 11 (disabled) and SEC=10 (unsecured). Ok.  Let's try to verify the device is blank:

J-Link>mem8 40020006 1

40020006 = 80

J-Link>w1 40020002 0

Writing 00 -> 40020002

J-Link>w1 4002000a 1

Writing 01 -> 4002000A

J-Link>mem8 40020006

J-Link>w1 40020006 80

Writing 80 -> 40020006

J-Link>mem8 40020006 1

40020006 = 83

Here we see that the MGSTAT bits in FSTAT indicate that blank check has failed and also that non-correctable errors were found. Odd.  Let's try erasing it ourselves:

J-Link>w1 40020002 0

Writing 00 -> 40020002

J-Link>w1 4002000a 8

Writing 08 -> 4002000A

J-Link>w1 40020006 80

Writing 80 -> 40020006

J-Link>mem8 40020006 1

40020006 = 80

The erase all command succeeded. Now let's try a blank check:

J-Link>w1 40020002 0

Writing 00 -> 40020002

J-Link>w1 4002000a 1

Writing 01 -> 4002000A

J-Link>w1 40020006 80

Writing 80 -> 40020006

J-Link>mem8 40020006 1

40020006 = 80

Now the blank check is fine?

At this point I'm about ready to give up, eat the loss on these prototypes and go with a processor from ST where I've never had these kinds of issues before. The Kinetis documentation is thorough enough but it is very dense and I'm finding it very difficult to get started. I can wiggle I/O through memory reads and access other peripherals but I can't for the life of me figure out what's wrong with the flash controller.  I've been working with micros for over 20 years and this kind of difficulty is something I have never encountered before.

Edited to include walkthrough of the device state and flash erase attempt

Added schematic page showing MCU, power supplies and SWD interface

[Hui_Ma]

Hi Andrew,

Can you run "unlock Kinetis" command normally at J-Link Commander tool?

Have a great day,
best regards,

Ma Hui

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

[akohlsmith]

Good afternoon, Hui_Ma,

I can execute the command and it pauses for several seconds (much like "flash erase") but then JLinkExe says that a timeout occurred. I don't get any other information which may help in diagnosing the issue.

[Hui_Ma]

Could you post your KEA SWD interface related circuit for review?

I also would recommend to refer TRK-KEA64 board schematics as an reference.

Wish it helps.

Have a great day,
best regards,

Ma Hui

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

[akohlsmith]

There isn't anything to the SWD interface; SWDCK, SWDIO and RST# go to the J-Link Lite. Neither RST# nor NMI# have pullups, but the documentation states clearly that an internal pullup is present (section 12.2.2 in the RM).

I've added the relevant page from my schematic. SWDCK, SWDIO and RST connect directly to the SWD connector and nothing else.

edit: 20141230 22:48

I used SIM_SOPT to disable the external reset pin and this allowed the J-Link Commander to "unlock kinetis" correctly. However nothing worked after that because the CPU could not be stopped. (e.g. I could not issue "erase flash" or even halt the CPU):

Info: Found SWD-DP with ID 0x0BC11477

Info: Found SWD-DP with ID 0x0BC11477

Info: Found Cortex-M0 r0p0, Little endian.

Info: FPUnit: 2 code (BP) slots and 0 literal slots

Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit.

J-Link>r

Reset delay: 0 ms

Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit.

J-Link>h

PC = FFFFFFFE, CycleCnt = 00000000

R0 = 08614405, R1 = 80A08004, R2 = 010540A0, R3 = 04000400

R4 = 00400920, R5 = 8C018008, R6 = 00080042, R7 = 01004060

R8 = 02000888, R9 = 00212402, R10= 04000011, R11= 90040044

R12= 04989040

SP(R13)= FFFFFFFC, MSP= FFFFFFFC, PSP= 000C8200, R14(LR) = FFFFFFF9

XPSR = 41000000: APSR = nZcvq, EPSR = 01000000, IPSR = 000 (NoException)

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

J-Link>unlock kinetis

Unlocking device...Timeout while unlocking device.

Now if I disable the reset pin:

J-Link>w4 40048004 8

Writing 00000008 -> 40048004

J-Link>unlock kinetis

Unlocking device...O.K.

But now the CPU cannot be halted:

J-Link>h

WARNING: CPU could not be halted

J-Link>h

WARNING: CPU could not be halted

J-Link>erase

Erasing device (SKEAZN64xxx2)...

****** Error: Can not read register 16 (XPSR) while CPU is running

****** Error: Can not read register 20 (CFBP) while CPU is running

****** Error: Can not read register 0 (R0) while CPU is running

****** Error: Can not read register 1 (R1) while CPU is running

****** Error: Can not read register 2 (R2) while CPU is running

****** Error: Can not read register 3 (R3) while CPU is running

****** Error: Can not read register 4 (R4) while CPU is running

****** Error: Can not read register 5 (R5) while CPU is running

****** Error: Can not read register 6 (R6) while CPU is running

****** Error: Can not read register 7 (R7) while CPU is running

****** Error: Can not read register 8 (R8) while CPU is running

****** Error: Can not read register 9 (R9) while CPU is running

****** Error: Can not read register 10 (R10) while CPU is running

****** Error: Can not read register 11 (R11) while CPU is running

****** Error: Can not read register 12 (R12) while CPU is running

****** Error: Can not read register 14 (R14) while CPU is running

****** Error: Can not read register 15 (R15) while CPU is running

****** Error: Can not read register 17 (MSP) while CPU is running

****** Error: Can not read register 18 (PSP) while CPU is running

****** Error: Failed to prepare for programming.

Could not read target memory.

Please check your flash settings!

ERROR: Erase returned with error code -1.

WARNING: CPU could not be halted

J-Link>moe

CPU is not halted.

J-Link>r

Reset delay: 0 ms

Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit.

Info: SYSRESETREQ has confused core. Trying to reconnect and use VECTRESET.

Info: Found SWD-DP with ID 0x0BC11477

WARNING: Failed to reset CPU. VECTRESET has confused core.

WARNING: CPU did not halt after reset.

WARNING: CPU could not be halted

Info: Core did not halt after reset, trying to disable WDT.

WARNING: CPU did not halt after reset.

WARNING: CPU could not be halted

WARNING: Could not set S_RESET_ST

Info: Found SWD-DP with ID 0x0BC11477

WARNING: Could not set S_RESET_ST

WARNING: CPU did not halt after reset.

WARNING: CPU could not be halted

Info: Core did not halt after reset, trying to disable WDT.

WARNING: CPU did not halt after reset.

WARNING: CPU could not be halted

WARNING: Could not set S_RESET_ST

WARNING: CPU could not be halted

****** Error: Could not power up debug port: Control/Status register reads 0BC11477

J-Link>h

WARNING: CPU could not be halted

Is there an example project for KDS which already has the correct configuration for J-Link and the SKEAZN64? I simply cannot believe that this is this difficult. I'm working off of 3.3V; is this an issue? The datasheet says that the part and all its peripherals should work in their full capacity down to 2.7V.

The schematic for the TRK-KEA64 really shows nothing unusual or interesting for the SWD interface (or anything for that matter) -- it's just direct-wired to the debug port. No pullups/downs, no unusual filtering or strapping.

I'm stumped.

[Hui_Ma · Accepted solution]

Hi,

I got the info from Segger, and they indeed identified the problem.

They plan to release a new Segger firmware either this or next week.

Thank you for the attention.

Have a great day,
best regards,

Ma Hui

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

[akohlsmith]

I've confirmed that as of JLink v4.96a (the 'a' is important, v4.96 did not work) I am able to both program and debug my KEA64 design in KDS using the J-Link Lite Cortex-M adapter.

Thank you very much.

[Hui_Ma]

Hi,

Sorry for the later reply.

I tried to use KDS software created a project and debug with TRK-KEA64 board without success. There always shows the debugger connection error.

I also tried to use CodeWarrior MCU V10.6 to debug project with TRK-KEA64 board, whatever P&E OPENSDA or Segger J-Link works as expected.

So, I think there exists problem with KDS software with KEA chip. I will forward related info to KDS software team.

The KEA product should work with 3.3V VDD powered.

I would prefer customer could try with CodeWarrior MCU V10.6 software, which could support up to 64KB free code size.

The TRK-KEA64 example code for CW could be downloaded from here:

Wish it helps.

Have a great day,
best regards,

Ma Hui

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