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.
10 years, 6 months ago.
Is there a problem with pyocd on FRDM-KL25Z?
I refer you all to a question posted by user http://mbed.org/users/floha/ and myself.
http://mbed.org/questions/1626/bricked-by-debuger/
Both of us experienced bricking of our FRDM-KL25Z boards after we used pyocd to flash our .elf images
(As a side note, my program works fine through the drag and drop method)
This happened because the device flash security bytes seems to have been written with some values which protects the memory and prevents debugger access as well (including mass erase).
I have checked my linker script (which I got off the mbed github repository for KL25Z), the memory map seems to take care of the flash protect areas. I did some digging, and I suspect this has something to do with the pyocd flashing algo.
Inside flash_kl25z.py, it seems like the memory map xml does not take care of the flash protect regions. I'm not sure if this is the root cause.
memoryMapXML = "<?xml version=\"1.0\"?>" \
"<!DOCTYPE memory-map PUBLIC \"+//IDN gnu.org//DTD GDB Memory Map V1.0//EN\" \"http://sourceware.org/gdb/gdb-memory-map.dtd\">" \
"<memory-map>" \
"<memory type=\"flash\" start=\"0x0\" length=\"0x20000\"> <property name=\"blocksize\">0x400</property></memory>" \
"<memory type=\"ram\" start=\"0x20000000\" length=\"0x3000\"> </memory>" \
"</memory-map>"
Would appreciate if the mbed team can confirm this, as I'm a little apprenhensive about fixing this myself and then bricking another board =P
Cheers,
Timothy
1 Answer
10 years, 6 months ago.
If your KL25Z board enters in flash protection mode after the crash of pyocd, please refer to my solution here to recover it.
The flash protection feature cause a discontinuous and unique flash memory layout on KL25Z. The isr_vector table and some initializaiton code should be saved in the first region from 0x0 to 0x400, then the special values for flash protection should be saved in second region from 0x400 to 0x410, the remaing spaces after 0x410 are for text/data and other sections.
It's common that the first region won't be occupied fully because isr_vector table is samll usually. Then some spaces in first region will be left as a gap. The pyocd has a problem to handle such discontinuous memory layout. It will wrongly write the values for flash protection to flash address right after the end of isr_vector table section, not the expected address 0x400.
To workaround this issue, please enlarge your isr_vector table section to occupy the whole region from 0x0 to 0x400. Then when upload this kind of image, the flash protection values will be written to expected address. If you are using GNU ARM tool chain, you can rewrite your linker script like:
code to show how to fill the section
MEMORY
{
VECTORS (rx) : ORIGIN = 0x00000000, LENGTH = 0x00000400
FLASH_PROTECTION (rx) : ORIGIN = 0x00000400, LENGTH = 0x00000010
FLASH (rx) : ORIGIN = 0x00000410, LENGTH = 128K - 0x00000410
RAM (rwx) : ORIGIN = 0x1FFFF0C0, LENGTH = 16K - 0xC0
}
ENTRY(Reset_Handler)
SECTIONS
{
.isr_vector :
{
__vector_table = .;
KEEP(*(.vector_table))
*(.text.Reset_Handler)
*(.text.System_Init)
. = 0x400;
} > VECTORS =0xFF /* Fill the rest of the section with garbage value 0xFF until address 0x400. */
Hi Terry,
Thanks for your answer. I have tried your solution. I'm only able to change the firmware to MSD-FRDM-KL25Z_Pemicro_v112.SDA and see the FRDM-KL25Z mass storage on my computer, but the precompiled binaries were not able to be flashed successfully. The yellow LED keeps blinking and the binary does not get loaded after a drag and drop.
I'm pretty sure that my FRDM board is bricked (see my log above)
I'm wondering if this is the same scenario as yours after using pyocd? Or could I have done something in addition that would disable mass erase in addition to flash protection? As far as I can remember, I've ever only used pyocd and it's bricked with flash protection and mass erase disable (permanently locked)
Cheers,
Timothy
Hello Timothy Teh,
the linker script takes care of flash protect areas because while I was writing it, I locked chip few times. I had to use external Jlink to unlock the chip. I haven't use pyOCD yet, I can take a look at it to try it here. Any tutorial outside of mbed to run it or just search mbed website to find all info ?
A question aside for my research, I would like to ask is why do you use pyOCD and not openOCD or Jlink gdb? I have been using jlink gdb without any problems so far.
Regards,
posted by Martin Kojtal 08 Oct 20130xc0170
Hi Martin,
Thanks for your reply. I simply followed the instructions for pyOCD on https://mbed.org/blog/entry/Debugging-from-GDB-using-pyOCD/ (there is a bug with the pywinusb_backend.py you can see my fix there in the comments)
You'll need to have the following installed:
Run the gdb_test.py script to start a gdb server on localhost:3333.
pyOCD was my first foray into using gdb, that's how I got started. However, now I am thinking of using jlink - at least for the FRDM-KL25Z!
Until we fix the problem =) Thanks again for your help!
Cheers,
posted by Timothy Teh 08 Oct 2013Timothy
Timothy, Could you test it with Jlink gdb?
Do you have board which is locked? I replied to original thread, http://mbed.org/questions/1626/bricked-by-debuger/#answer1940, to use jlink opensda to unlock the chip. I have used only external Jlink so this is just a hypothesis.
How did you create your project you shared there on that question? Where did you take that makefile from? I review your shared bin, looks good (the protection region is filled with the proper data).
Regards,
posted by Martin Kojtal 08 Oct 20130xc0170
Hi Martin,
I adapted the makefile from lpc1768 makefile. I have tried to unlock the KL25Z using jlink commander. I've attached the log here:
/media/uploads/timothyteh/jlink.log
As you can see, the device is very much locked. I read the mdm-ap status register and it returns 0x1E, which means that the device is secured and mass erase is disabled =(
I also think that the problem could perhaps be related to the flash algorithm downloaded to ram in pyocd flash_kl25z.py.
p.s. You may not want to really try loading using pyocd, since I'm pretty sure you will get bricked.
Cheers, Timothy
posted by Timothy Teh 08 Oct 2013Thanks for your info. I also wrote a makefile for KL25Z mbed, I also described how to use it with jlink gdb.
Your KL25Z is bricked :( I'll find out who's responsible for that KL25Z script there.
Martin
posted by Martin Kojtal 08 Oct 2013Hi Martin,
Got my 2nd FRDM board today, this time I used jlinkGDBServer, and there were no problems whatsoever.
I used the exact same .elf file to load into the board, and could start debugging. So there is definitely something wrong with pyocd!
Cheers,
posted by Timothy Teh 10 Oct 2013Timothy
Thanks for heads up. I have been using jlink gdb without any problems so far. I talked to mbed team, they ticketed an issue, but wont fix immediately. They will notify you through this thread I guess.
Have fun with KL25Z !
posted by Martin Kojtal 10 Oct 2013