Commit Graph

3 Commits (739d16d503e4a446d28e43e025f3b355d262b51f)

Author SHA1 Message Date
Paul Fertser c7384117c6 Allow transports to override the selected target (hla configs unification)
This should allow to share common configs for both regular access and
high-level adapters.

Use the newly-added functionality in stlink and icdi drivers, amend
the configs accordingly.

Runtime-tested with a TI tm4c123g board.

Change-Id: Ibb88266a4ca25f06f6c073e916c963f017447bad
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
[gus@projectgus.com: context-specific deprecation warnings]
Signed-off-by: Angus Gratton <gus@projectgus.com>
[andrew.smirnov@gmail.com: additional nrf51.cfg mods]
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Tested-by: Andrey Skvortsov <andrej.skvortzov@gmail.com>
Reviewed-on: http://openocd.zylin.com/1664
Tested-by: jenkins
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
2014-08-11 21:25:56 +00:00
Andrey Smirnov 46101959a6 kinetis: Revise CPU un-securing code
Old version of the code had several problems, among them are:
 * Located in a generic ADI source file instead of some Kinetis
   specific location
 * Incorrect MCU detection code that would read generic ARM ID
   registers
 * Presence of SRST line was mandatory
 * There didn't seem to be any place where after SRST line assertion
   it would be de-asserted.
 * Reset was asserted after waiting for "Flash Controller Ready" bit
   to be set, which contradicts official programming guide AN4835
 * Mass erase algorithm implemented by that code was very strange:
   ** After mass erase was initiated instead of just polling for the
      state of "Mass Erase Acknowledged" bit the code would repeatedly
      initiate mass erase AND poll the state of the "Mass Erase
      Acknowledged"
   ** Instead of just polling for the state of "Flash Mass Erase in
      Progress"(bit 0 in Control register) to wait for the end of the
      mass erase operation the code would: write 0 to Control
      register, read out Status register ignoring the result and then
      read Control register again and see if it is zero.
 * dap_syssec_kinetis_mdmap assumed that previously selected(before
   it was called) AP was 0.

This commit moves all of the code to kinetis flash driver and
introduces three new commands:

o "kinetis mdm check_security" -- the intent of that function is to be used as
  'examine-end' hook for any Kinetis target that has that kind of
  JTAG/SWD security mechanism.

o "kinetis mdm mass_erase""  -- This function removes secure status from
  MCU be performing special version of flash mass erase.

o "kinetis mdm test_securing" -- Function that allows to test securing
  fucntionality. All it does is erase the page with flash security settings thus
  making MCU 'secured'.

New version of the code implements the algorithms specified in AN4835
"Production Flash Programming Best Practices for Kinetis K-
and L-series MCUs", specifically sections 4.1.1 and 4.2.1.
It also adds KL26 MCU to the list of devices for which this security
check is performed. Implementing that algorithm also allowed to simplify
mass command in kinetis driver, since we no longer need to write security
bytes. The result that the old version of mass erase code can now be
acheived using 'kinetis mdm mass_erase'

Tested on accidentally locked FRDM-KL26Z with KL26 Kinetis MCU.

Change-Id: Ic085195edfd963dda9d3d4d8acd1e40cc366b16b
Signed-off-by: Andrey Smrinov <andrew.smirnov@gmail.com>
Reviewed-on: http://openocd.zylin.com/2034
Tested-by: jenkins
Reviewed-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
2014-05-10 09:15:35 +00:00
Paul Fertser da7f048104 target: add kl25z HLA (stlink) config
Based on Nemuisan Tokusei's. Untested, but original config was reported
to work ok.

Change-Id: Ic991dce55bfca266880081fe2bbd9e6e263b0fc0
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/1803
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
2013-12-19 19:54:55 +00:00