Sorry for the late reply: I wanted to make sure I had my Olimex debugger handy
before I tried flashing the KW01 board with the ST-Link again, and I had left
it in the office. :)
The released version of OpenOCD that I used when I ran into this problem didn't
have that change in it. I think I tried something very similar but I recall
still having problems regarding the second issue that I mentioned even after I
tried that, so I focused on the kinetis.c flash module instead.
In any case, I just checked out the latest code from the git repo (and
confirmed that the change you mentioned was there), did a build, and tested
again with the ST-LINK v2, and it seems like it does work correctly now:
Open On-Chip Debugger 0.10.0+dev-00670-g7345801b-dirty (2019-01-28-19:13)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override
use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results
might differ compared to plain JTAG/SWD
Info : add flash_bank kinetis klx.pflash
adapter speed: 1000 kHz
none separate
!!!!!!!!!!!!!!!!!!!!!! WARNING !!!!!!!!!!!!!!!!! WARNING !!!!!!!!!!!!!!!!!!!!!!
Kinetis MCUs have a MDM-AP dedicated mainly to MCU security related functions.
A high level adapter (like a ST-Link) you are currently using cannot access
the MDM-AP, so commands like 'mdm mass_erase' are not available in your
configuration. Also security locked state of the device will not be reported.
Be very careful as you can lock the device though there is no way to unlock
it without mass erase. Don't set write protection on the first block.
!!!!!!!!!!!!!!!!!!!!!! WARNING !!!!!!!!!!!!!!!!! WARNING !!!!!!!!!!!!!!!!!!!!!!
force hard breakpoints
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 1000 kHz
Info : STLINK V2J21S4 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.235813
Info : klx.cpu: hardware has 2 breakpoints, 2 watchpoints
Info : Listening on port 3333 for gdb connections
Info : accepting 'gdb' connection on tcp/3333
Info : Kinetis MKL16Z128xxx4 detected: 1 flash blocks
Info : 1 PFlash banks: 128k total
target halted due to debug-request, current mode: Thread
xPSR: 0x41000000 pc: 0x00000410 msp: 0x1ffff100
Info : Disabling Kinetis watchdog (initial SIM_COPC 0x0c)
Info : This device supports Program Longword execution only.
Warn : not enough working area available(requested 2048)
Info : Padding image section 0 at 0x000000c0 with 64 bytes
Info : Padding image section 1 at 0x000003a4 with 92 bytes
Info : This device supports Program Longword execution only.
Warn : not enough working area available(requested 2048)
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x00000410 msp: 0x1ffff100
I hadn't realized this was already addressed. (I haven't used this particular
board in a while.) I'll close the ticket. (If I can figure out how...)
Thanks!
-Bill
---
** [tickets:#222] Flashing NXP Kinetis with ST-LINK V2 dongle fails, leaves
flash locked**
**Status:** new
**Milestone:** 0.9.0
**Created:** Sat Jan 26, 2019 09:43 PM UTC by Bill Paul
**Last Updated:** Sat Jan 26, 2019 09:43 PM UTC
**Owner:** nobody
**Attachments:**
-
[kinetis.c.diff](https://sourceforge.net/p/openocd/tickets/222/attachment/kinetis.c.diff)
(3.6 kB; text/x-patch)
A while ago, a friend and I created a project based on the NXP Kinetis KW01
chip, which has a Cortex-M0+ core , 16KB RAM and 256KB flash. We included a
10-pin header for SWD. We used OpenOCD with the Olimex USB-ARM-OCD-H debugger
and everything worked perfectly.
Later, I acquired a cheap ST-LINK V2 clone dongle and decided to see how it
worked with our board. I was able to debug just fine, but when I try and
re-flash the firmware, the flash process terminated with an error almost
immediately, and after that the MCU was locked. I was able to recover it using
the Olimex debugger to issue a kinetis mass_erase command. This requires a
low-level debugger, so it can't be done with the ST-LINK V2.
I was able to eventually patch the kinetis.c flash driver to correct the
problems. I identified two issues.
The first has to do with the way the ST-LINK V2 performs write accesses. It
performs an automatic verify on write, which means that after a write
transaction is issued, it then peforms a read tranaction to the same location
and compares the result with what it tried to write. If they don't match, then
the dongle returns an error status.
It turns out this behavior conflicts a bit with the behavior of the Kinetis
flash controller. To start a flash operation, you write a 1 to bit 7 (0x80) of
the FTFx_STAT register. This bit also indicates command completion: once you
write a 1 to it, it will automatically clear and stay clear until the flash
command completes. So to check for completion, you poll the FTFx_STAT register
until bit 7 becomes set again.
The problem is, since the bit clears as soon as you write to it, this pretty
much guarantees that when the dongle automatically reads back the register
after writing it to it, the value it reads will not match what it wrote, so it
will return a verification error.
The kinetis_ftfx_command() function sees this return status from
target_write_u8() and thinks issuing the command failed, so it aborts the whole
flash update process. In reality though, the command has succeeded. Usually
this command is an erase.
It also happens that the Kinetis parts have flash security registers whose
values are loaded from offset 0x400 in the flash. Due to the above problem,
these locations will be erased and then not properly re-written again. (If I
remember right, the kinetis.c driver has code in it specifically to update this
flash configuration field, but we never get to it because the whole flash
update has been aborted.) The result is that now if you reset or power-cycle
the MCU, it will load the security registers with values that put the chip into
a secure state, and now you've basically locked yourself out of the device with
no way to recover unless you happen to also have a low-level debugger handy.
Ironically, immediately after the target_write_u8(), there's a loop that reads
the FTFx_STAT register to check for command completion, which works correctly.
I patched the kinetis_ftfx_command() function to remove the test of the return
status from target_write_u8( ) and just rely on the completion check loop to
detect if there was a problem executing the command, and this corrected this
problem.
The second issue has to do with the update of the flash config field itself,
which is done in kinetis_erase() using kinetis_write_inner(). Normally flash
updates are done with a fast block update algorithm. Even with the above fix, I
found that sometimes this can also fail. I suspect there's a similar timing
problem involved as with the first issue, but I'm not certain where.
I was able to correct this problem by forcing the code to fall back to the slow
write method just for this one operation. (That way updating the rest of the
flash is still quick.)
I'm attaching a patch for the kinetis.c module which applies both these fixes.
With this patch I can reflash the firmware in our KW01 board with the ST-LINK
V2 reliably. (At least, I wasn't' able to get it to fail again with the fixes
in place.) I'm not necessarily suggesting these fixes be used verbatim because
I don't have any other Kinetis parts to check it against. Hopefully someone
with access to more devices can do some better validation.
---
Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is
subscribed to https://sourceforge.net/p/openocd/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list._______________________________________________
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
