Important changes to forums and questions

All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.

pyOCD, KL25Z (locking?)

Topic last updated 17 Dec 2013, by Martin Kojtal. 9 replies
Martin Kojtal
02 Dec 2013

I am starting this thread, to gather information about KL25Z and pyOCD. There were 2 users who reported that they had locked chip using pyOCD. Timothy Teh and Flo rian, please provide some details, here's link to the question thread:

http://mbed.org/questions/1626/bricked-by-debuger/#answer2075

Did you change pyOCD anyhow? What script did you use to flash KL25Z?

I was testing pyOCD the last weekend. I flashed my KL25Z (using basic_test.py in test folder, just supplied it with -f myfile.bin) few times with a simple application and flashed also the provided bin file in binaries/l1_kl25z.bin, not locked after all. A question is how did you manage to lock your KL25Z?

Best would be, if you describe your procedure, Flo rian, you mentioned you used elf file through gdb?

@Timothy, you even shared your project which caused the lock. I reviewed the binary file, the region 0x400 is properly set. I can flash it today.

@Flo rian, can you share your project, which caused the lock?

Regards,
0xc0170

Martin Kojtal
02 Dec 2013

Hello guys,

I was using pyOCD scripts, thus I was not able to replicate locking. I run today gdb, eclipse connected to gdb. The result? I locked KL25Z.

Here's the output from the gdb console http://pastebin.com/6LVKq3GH. Might help to track what did go wrong.

The elf file used for flashing /media/uploads/Kojto/mbed.elf . Elf file should be ok, using bin file created frmo this elf file, works using pyOCD scripts and also msd mbed, or jlink gdb.

Regards, 0xc0170

Martin Kojtal
03 Dec 2013

I could not connect through ULINK, neither Jlink console. It looked like it destroyed completely flash, but fortunately it did not set mass erased bit. I used external Jlink, it failed to connect - did not recognize a core, thus I added a device and unlocked the chip. Since then it's working again.

Here's an output from jlink console (I accidentally selected KL26 chip, same footprint though):

SEGGER J-Link Commander V4.76f ('?' for help)
Compiled Sep 27 2013 16:54:08
DLL version V4.76f, compiled Sep 27 2013 16:53:51
Firmware: J-Link Lite-FSL V1 compiled Jun 25 2012 16:40:07
Hardware: V1.00
S/N: 361000149
VTarget = 2.874V
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

****** Error: Error while identifying Cortex-M core.
Info: Found SWD-DP with ID 0x0BC11477
No device found on SWD.
Failed to identify target. Trying again with slow (4 kHz) speed.
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

****** Error: Error while identifying Cortex-M core.
Info: Found SWD-DP with ID 0x0BC11477
No device found on SWD.
J-Link>device ?
Info: Device "MKL26Z128XXX4" selected (128 KB flash, 16 KB RAM).
Reconnecting to target...
Info: Could not measure total IR len. TDO is constant high.
Info: Could not measure total IR len. TDO is constant high.
J-Link>unlock kinetis
Unlocking device...O.K.
J-Link>SWDReadAP 0x1000000
Read AP register 16777216 = 0x00000000
J-Link>SWDReadAP 0x1000000
Read AP register 16777216 = 0x00000031
J-Link>erase
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
Info: Kinetis L-series (setup): Disabling watchdog.
Erasing device (MKL26Z128xxx4)...
Info: J-Link: Flash download: Flash programming performed for 1 range (1024 byte
s)
Info: J-Link: Flash download: Total time needed: 1.086s (Prepare: 0.465s, Compar
e: 0.143s, Erase: 0.017s, Program: 0.047s, Verify: 0.012s, Restore: 0.399s)
Erasing done.
J-Link>

Regards,
0xc0170

Martin Kojtal
03 Dec 2013

I disabled flashing today, and was looking at what's happening there. When FlashWrite is executed, looks like data are interpreted incorrectly.

First 40 lines from flashData:

0030 0020 c100 0000 2505 0000 2705 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 2905 0000
0000 0000 0000 0000 2b05 0000 2d05 0000
3105 0000 3305 0000 3505 0000 3705 0000
2f05 0000 3905 0000 3b05 0000 3d05 0000
3f05 0000 4105 0000 4305 0000 4505 0000
4705 0000 4905 0000 4b05 0000 4d05 0000
4f05 0000 5105 0000 5305 0000 5505 0000
5705 0000 5905 0000 5b05 0000 2f05 0000
5d05 0000 5f05 0000 6105 0000 6305 0000
6505 0000 2f05 0000 6705 0000 6905 0000
0749 084a 084b 9b1a 05dd 007d 0408 5910
5104 349c 42fa db05 4880 4705 4800 4700
0030 6c00 00c0 f0ff 1f9c f1ff 1fad 0500
0071 0400 00ff ffff ffff ffff ffff ffff
fffe ffff ff10 b506 4c7d 0378 002b 07d1
0548 0028 02d0 0448 00e0 00bf 0121 2170
10bd 9cf1 ff1f 0000 0000 7d04 6c00 0008
b508 4b00 2b03 d007 4808 4900 e000 bf07
4801 6800 2903 d006 4a00 2a00 d090 4708
bdc0 4600 0000 007d 046c 0000 a0f1 ff1f
9cf1 ff1f 0000 0000 164b 002b 00d1 144b
9d46 4022 9202 9a1a 9246 0021 8b46 0f46
1348 144a 121a 00f0 0efd 0f4b 002b 00d0
9847 0e4b 002b 00d0 9847 0020 0021 0446
0d46 0020 0c49 0022 007d 0300 f057 fc00
f077 fc20 4629 4600 f011 f800 f0c9 f8c0
4600 0008 0000 3000 2000 0000 0000 0000
009c f1ff 1ff0 f2ff 1f7d 5d0d 0000 10b5
074c 0748 e368 6268 1a60 00f0 ecf8 2069
6168 0160 0348 00f0 e6f8 f1e7 c046 b8f1
ff1f cdcc 4c3e 08b5 0348 0349 0122 00f0
02f9 08bd c046 b8f1 ff1f 4c10 0000 fee7
fee7 fee7 fee7 fee7 fee7 fee7 fee7 fee7
fee7 fee7 fee7 fee7 fee7 fee7 fee7 fee7
fee7 fee7 fee7 fee7 fee7 fee7 fee7 fee7
fee7 fee7 fee7 fee7 fee7 fee7 fee7 fee7
fee7 fee7 c046 0d4a f0b5 9368 9568 1f1c
002d 0fd1 1f1c 0d0a 4dc0 371c 1c40 cc2a

Actual bin file from the elf:

0030 0020 c100 0000 2505 0000 2705 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 2905 0000
0000 0000 0000 0000 2b05 0000 2d05 0000
3105 0000 3305 0000 3505 0000 3705 0000
2f05 0000 3905 0000 3b05 0000 3d05 0000
3f05 0000 4105 0000 4305 0000 4505 0000
4705 0000 4905 0000 4b05 0000 4d05 0000
4f05 0000 5105 0000 5305 0000 5505 0000
5705 0000 5905 0000 5b05 0000 2f05 0000
5d05 0000 5f05 0000 6105 0000 6305 0000
6505 0000 2f05 0000 6705 0000 6905 0000
0749 084a 084b 9b1a 05dd 0024 0859 1051
0434 9c42 fadb 0548 8047 0548 0047 0000
306c 0000 c0f0 ff1f 9cf1 ff1f ad05 0000
7104 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000

They start to differ on the line 13. Then data starts to be same after dozen of lines. This would explain locking the chip, the area at 0x400 is actually somewhere lower.

Regards,
0xc0170

Samuel Mokrani
07 Dec 2013

Hi Martin,

Hmm that is weird. flash_data really contains the raw values sent from GDB. pyOCD just put the raw data in this buffer.

You can sniff all the packets sent between gdb and pyocd by hitting "set debug remote" in your gdb console. The you will see if the data sent by gdb are correct or not.

Which toolchain are using to compile and debug?

Thanks, Sam

Adam Green
07 Dec 2013

My suspicion is that GDB is sending the flash image over in 3 separate chunks because of the use of the VECTORS, FLASH_PROTECTION, FLASH memory sections in https://github.com/mbedmicro/mbed/blob/master/libraries/mbed/targets/cmsis/TARGET_Freescale/TARGET_KL25Z/TOOLCHAIN_GCC_ARM/MKL25Z4.ld to represent the data which goes into the flash memory of the device. I don't currently have access to a KL25Z to test on but I wonder if it might truncate or round up the size of each of these sections as it writes them to pyOCD?

You might want to try modifying https://github.com/mbedmicro/pyOCD/blob/master/pyOCD/gdbserver/gdbserver.py#L331 to also dump the length of each write to see if they are overlapping or contain gaps. A workaround would be to modify the MKL25Z4.ld file to more closely mimic https://github.com/mbedmicro/mbed/blob/master/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC11UXX/TOOLCHAIN_GCC_ARM/TARGET_LPC11U24_401/LPC11U24.ld for locating the flash protection bits within a single FLASH memory region. Fixing pyOCD to correct the problem would be even better :)

Sorry that I can't test this theory out myself but I just thought that these observations might help in your current investigation.

-Adam

Martin Kojtal
15 Dec 2013

Hello guys,

thank you very much Adam and Samuel for suggestions which helped me to find an issue with locking the freescale chips. This is a moment when I appreciate sharing with community.

I had to edit the linker command file according to Adam's suggestions (one section for vectors and flash protection bits). The problem was that gdb ignored the unused space in the VECTORS section. More info here http://pastebin.com/zLCAkTh8 - line 148. That section's size should be 0x400.

Although I was able to load the image and not to lock it, it got trapped in the resetStopOnReset. When I run pyOCD gdb server and connect to it from eclipse, it loaded the image but was so slow that I waited like 30 seconds to flash KL25Z, then it did not run properly. I'll get onto this 2 issues soon, I havent got time today to investigate more, was fixing couple of other issues.

Regards, 0xc0170

Samuel Mokrani
16 Dec 2013

Hi Martin,

I really think that pyOCD has to be fixed to handle non consecutive blocks coming from gdb. At the moment, even if pyOCD receives non consecutive blocks, it will create an array by just accumulating the blocks... There are different ways to fix that in pyOCD (without changing any scatter files or linker scripts). The simplest is probably to do some padding in the flashData array when we detect that the address of the block that we are currently receiving does not match with the address of the previous block + the size of the previous block.

Cheers, Sam

Martin Kojtal
16 Dec 2013

Samuel Mokrani wrote:

Hi Martin,

I really think that pyOCD has to be fixed to handle non consecutive blocks coming from gdb. At the moment, even if pyOCD receives non consecutive blocks, it will create an array by just accumulating the blocks... There are different ways to fix that in pyOCD (without changing any scatter files or linker scripts). The simplest is probably to do some padding in the flashData array when we detect that the address of the block that we are currently receiving does not match with the address of the previous block + the size of the previous block.

Cheers, Sam

Yes, I agree. I was thinking about the same based on the data I collected. I simply needed to fix it as soon as possible so no more KL25Z would be locked. I am going to look at pyOCD server. If I come up with anything, I'll share it here.

Regards,
0x0170

Martin Kojtal
17 Dec 2013

Hello Samuel,

here's my proposed fix, I have to add a function to check security bits for target KL25Z, please review:

https://github.com/mbedmicro/pyOCD/pull/2

Regards, 0xc0170