this is to avoid confusion with STM32 L4, L4+ and L5 families
also:
- a warning message is changed to error
- stm32l0x and stm32l1x aliases has been created to permit
the usage of either names
Change-Id: If3f16d2a3b7d1369959aa7407da37a9076ea91d7
Signed-off-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
Reviewed-on: http://openocd.zylin.com/5437
Reviewed-by: Marc Schink <dev@zapb.de>
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
To prepare for handling TCL return values consistently, all calls
to command_print/command_print_sameline should switch to CMD as
first parameter.
Change prototype of command_print() and command_print_sameline()
to pass CMD instead of CMD_CTX.
Since the first parameter is currently not used, the change can be
done though scripts without manual coding.
This patch is created using the command:
sed -i PATTERN $(find src/ doc/ -type f)
with all the following patters:
's/\(command_print(cmd\)->ctx,/\1,/'
's/\(command_print(CMD\)_CTX,/\1,/'
's/\(command_print(struct command_\)context \*context,/\1invocation *cmd,/'
's/\(command_print_sameline(cmd\)->ctx,/\1,/'
's/\(command_print_sameline(CMD\)_CTX,/\1,/'
's/\(command_print_sameline(struct command_\)context \*context,/\1invocation *cmd,/'
This change is inspired by http://openocd.zylin.com/1815 from Paul
Fertser but is now done through scripting.
Change-Id: I3386d8f96cdc477e7a2308dd18269de3bed04385
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/5081
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Instances of struct flash_driver are never written to at runtime. For a
small amount of memory saving and also robustness (fewer things for
stray pointer writes to hit), mark them const.
Change-Id: Iadbbbc2fac0976d892699200000c5f02856729f3
Signed-off-by: Christopher Head <chead@zaber.com>
Reviewed-on: http://openocd.zylin.com/4803
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
Reviewed-by: Matthias Welwarsky <matthias@welwarsky.de>
This should allow users to configure flash at >32-bit addresses.
Change-Id: I7c9d3c5762579011a2d9708e5317e5765349845c
Signed-off-by: Tim Newsome <tim@sifive.com>
Reviewed-on: http://openocd.zylin.com/4919
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Make flash_driver methods protect() and protect_check()
optional.
Remove dummy definitions of these methods from the drivers
which do not implement protection handling.
Some drivers did not define protect method. It raised segfault
before this change and now it is handled properly.
Lot of drivers returned ERROR_OK from dummy protect()
- now flash_driver_protect() returns an error if not handled by the driver.
Change-Id: I2d4a0da316bf03c6379791b1b1c6198fbf22e66c
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: http://openocd.zylin.com/4765
Tested-by: jenkins
Reviewed-by: Andreas Bolsch <hyphen0break@gmail.com>
Reviewed-by: Christopher Head <chead@zaber.com>
Flash loaders refactored to the new style - use generated .inc
instead of hexadecimal machine code in the flash driver source.
Change-Id: If65a2099589e210f9450819b467d67819fd841fc
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: http://openocd.zylin.com/4439
Tested-by: jenkins
Reviewed-by: Matthias Welwarsky <matthias@welwarsky.de>
All drivers which simply allocate one driver_priv memory block
per each bank now use default_flash_free_driver_priv()
Change-Id: I425bf4213c3632f02dbe11ab819c31eda9b2db62
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: http://openocd.zylin.com/4417
Tested-by: jenkins
Reviewed-by: Liviu Dudau <liviu@dudau.co.uk>
Reviewed-by: Matthias Welwarsky <matthias@welwarsky.de>
Trying to read the L0 idcode at the L1 idcode address 0xE0042000 often
resulted in an uncatched error. Reading at the right L0 address 0x40015800
afterwards results in reading 0. So access to the device is denied..
Change-Id: I6de92cf99a5d5d46c72f9ba055613cbc5753a951
Signed-off-by: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Reviewed-on: http://openocd.zylin.com/3883
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
A footnote in RM0038r14.
Change-Id: Ic31894d846fbbe917a7290b2b7ff8fb582bb65da
Signed-off-by: Karl Palsson <karlp@tweak.net.au>
Reviewed-on: http://openocd.zylin.com/4198
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Default values for .first_bank_size_kb and .has_dual_banks fields
described in stm32lx_parts[] do not fully describe
the real device memory layouts.
Basing on:
STM32L0x1 RM0377
STM32L0x2 RM0376
STM32L0x3 RM0367
STM32Lxxxx RM0038
correct values for memory layouts were selected:
id = 0x447 STM32L0xx (Cat.5) <- dual bank flash
for size 192 or 128 KBytes, single bank for 64 KBytes
id = 0x436 STM32L1xx (Cat.4 / Cat.3 - Medium + /
High Density) <- only one size of the bank,
default values are correct
id = 0x437 STM32L1xx (Cat.5 / Cat.6) <- always dual bank,
but size of the bank can be different
For that reason .part_info field in struct stm32lx_flash_bank
is a dynamic field with fields copied from stm32lx_parts[]
and overwriten to correct values
for specific chips and memory sizes.
Change-Id: If638cb0a9916097bfd4eda77d64feaf1ef2d2147
Signed-off-by: Cezary Gapiński <cezary.gapinski@gmail.com>
Reviewed-on: http://openocd.zylin.com/4074
Tested-by: jenkins
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Fix "couldn't use loader, falling back to page memory writes" error on
stm32l0 which was caused by the use of cortex-m3 instructions in the
flash loader code. The loader is rewritten using cortex-m0 compatible
instructions
Signed-off-by: Armin van der Togt <armin@otheruse.nl>
Change-Id: If23027b8e09f74e45129e1f8452a04bb994c424e
Reviewed-on: http://openocd.zylin.com/4036
Tested-by: jenkins
Reviewed-by: Freddie Chopin <freddie.chopin@gmail.com>
struct flash_driver has a default_padded_value field that is similar,
but it can be changed by the user for the specific purpose of padding.
Add a new erased_value field and initialize it for all targets,
particularly stm32lx, xmc4xxx and virtual.
Use this value in core.c:default_flash_mem_blank_check(), the slow path.
Extend the target API to pass erased_value down to target code.
Adding an argument ensures that we catch all callers.
This allows us to merge xmc4xxx.c:xmc4xxx_blank_check_memory() into
armv7m:armv7m_blank_check_memory().
It further allows us to use default_flash_blank_check() in place of
xmc4xxx.c:xmc4xxx_flash_blank_check(), adding a potential slow path
fallback, as well as stm32lx:stm32lx_erase_check(), adding the potential
armv7m fast path with fallback to default_flash_mem_blank_check().
Fix a mips32 code comment while at it (zeroed -> erased).
The armv4_5 and mips32 target implementations will now error out if an
erase value other than 0xff is used, causing default_flash_blank_check()
to fall back to the default_flank_mem_blank_check() slow path.
Change-Id: I39323fbbc4b71c256cd567e439896d0245d4745f
Signed-off-by: Andreas Färber <afaerber@suse.de>
Reviewed-on: http://openocd.zylin.com/3497
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Also make GPL notices consistent according to:
https://www.gnu.org/licenses/gpl-howto.html
Change-Id: I84c9df40a774958a7ed91460c5d931cfab9f45ba
Signed-off-by: Marc Schink <openocd-dev@marcschink.de>
Reviewed-on: http://openocd.zylin.com/3488
Tested-by: jenkins
Reviewed-by: Andreas Färber <afaerber@suse.de>
Reviewed-by: Freddie Chopin <freddie.chopin@gmail.com>
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Obsolete C source code semicolons were removed using the semantic patch
semicolon/semicolon.cocci, see coccinellery.org
Change-Id: I153b4995a9e028ebaf5f58c947821dc78345a777
Signed-off-by: Alexander Kurz <akurz@blala.de>
Reviewed-on: http://openocd.zylin.com/3367
Tested-by: jenkins
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
RM0038 Rev.12 lists these new parts and introduces the category naming
scheme.
RM0367 Rev.2 (STM32L0x3 RM) doesn't add any new codes.
Change-Id: Id95dd48dda64d5f108dac57d265d29a7db3a1bd1
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Signed-off-by: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Reviewed-on: http://openocd.zylin.com/2495
Tested-by: jenkins
Commit 832f0a5bfb 'stm32: add mass erase support for STM32L' added
use of mass-erase in-place of bank-erase. This is triggered if first
bank is requested to be fully erased.
This erroneous action completely fails on STM32L162VEY (has 512 KiB
flash in two 256 KiB banks) and also unintently destroying contents of
EEPROM and second flash bank.
Change-Id: I0f13f7b0346747a09c755d72b5b95775ceff5a6f
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@haltian.com>
Reviewed-on: http://openocd.zylin.com/2441
Reviewed-by: Paul Fertser <fercerpav@gmail.com>
Tested-by: jenkins
Topaz reports on http://sourceforge.net/p/openocd/tickets/87/ that
protection level constants are mixed up. This leads to device ending
up in protection level 1 after mass erase.
Additional work is required to actually put the device in RDP Level 1
and then back to Level 0, as Option bootloader launch is a special
kind of full target reset.
To be able to flash properly after mass_erase a "reset init" is needed
(it's anyway recommended to always perform it before any flash
operation).
Change-Id: I9a838909458039bb0114d3019723bf134fa4d7c9
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/2490
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
The mass erase for STM32L was lack because the procedure is more complex
than the procedure for the STM32F4xx.
The reference manual RM0038 (L100 subfamily) page 79 is more accurate
than the reference manual for the STM32L0xx. On the L0, the mass-erase
erase also the EEPROM. This is a limit to mass erase on L0.
The mass erase procedure is a command of telnet interface.
Tested on Discovery L053 and Discovery L100.
Change-Id: I6a1d7a3669789aea89c59a006ab2d883f3d827ca
Signed-off-by: Rémi PRUD'HOMME <prudhomme.remi@gmail.com>
Reviewed-on: http://openocd.zylin.com/2319
Tested-by: jenkins
Reviewed-by: Andrey Yurovsky <yurovsky@gmail.com>
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
It's possible for us to fail to read the part ID code so make sure that
part_info is initialized to NULL before attempting to do so, otherwise
we could proceed and use it uninitialized and then segfault.
Change-Id: I0a3f3d3947690b66f0981b5046340449521e0b33
Signed-off-by: Jack Peel <jack.peel@synapse.com>
Signed-off-by: Andrey Yurovsky <yurovsky@gmail.com>
Reviewed-on: http://openocd.zylin.com/2276
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
This adds initial support for the STM32L0 family, specifically the ID
code 417 variant. The 'L0 has 128B rather than 256B pages as well as a
different number of pages per sector. It also has several key registers
and register sets in different locations from the STM32L1xx parts.
This change therefore takes the opportunity to reorganize part information into
a const table (it was previously determined by a set of control statements) and
abstracts away some of the low-level details to make them generic for L1 and
L0 parts.
We also include the first bank's size (for dual bank parts) in the new
device information table (and correct that size for the 0x437 variant
which is 256 rather than 192KB).
The 'L0 parts will not use the built-in loader/helper for Flash writing.
Tested on STM32L053 (dicovery board and Nucleo board) and STM32L152
(discovery board).
Change-Id: I57f7a8ab02caee266de71b31ae82a50d85728a0b
Signed-off-by: Andrey Yurovsky <yurovsky@gmail.com>
Reviewed-on: http://openocd.zylin.com/2200
Tested-by: jenkins
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Commit 2493671e2d added a default flash
padded value to the wrong file, should have been stm32lx.c not stm32f1x.c.
Change-Id: Idab634a03ccb28609cc977a92ac2b138d1e8d859
Signed-off-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-on: http://openocd.zylin.com/1833
Tested-by: jenkins
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Add device ID 0x437, a dual-bank part with 512KB total. This one used
the Medium+/HD flash size register to read the flash size in Kb rather
than the 0/1 code in the Medium+ parts.
Signed-off-by: Andrey Yurovsky <yurovsky@gmail.com>
Change-Id: I870fe3bb1b473939b7211c3b2edb44b4b3643648
Reviewed-on: http://openocd.zylin.com/1790
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
This eliminates most of the warnings reported when building for
arm-none-eabi (newlib).
Hsiangkai, there're many similar warnings left in your nds32 files, I
didn't have the nerve to clean them all, probably you could pick it
up.
Change-Id: Id3bbe2ed2e3f1396290e55bea4c45068165a4810
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/1674
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Unfortunately the Medium+ density and 0x436 devices have their F_SIZE register
at a different location: 0x1FF800CC instead of 0x1FF8004C. Fix this for
the 0x427 Medium+ devices and also the 0x436 devices. Furthermore, for
0x436 devices the flash size is reported as a 0 or 1 code rather than
the size in Kb. Please see RM0038 r8 or newer for an explanation, as
noted in the comments.
Change-Id: Ie03b1e119a61f2a854bc2ccc5f90ce3e8852e272
Signed-off-by: Andrey Yurovsky <yurovsky@gmail.com>
Reviewed-on: http://openocd.zylin.com/1522
Tested-by: jenkins
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Uppercase device/family names and change them to be more specific and
consistent across all STM32 families.
High-density STM32F10x has a Rev Y according to RM0008 Rev 14, so add
it.
I have a STM32F30x Rev Y, sitting on my desk, but it isn't described in
the reference manual. Add it as well.
Split the STM32L1xx Medium+ Density devices based on ID, to match the
reference manual. If I read it correctly, the Medium+ devices have
different revision mappings depending on their package/device ID. I have
no real devices to examine, however.
Change-Id: I5b95e5fa3cdeba219aa96838ea06ec1bb62bd921
Signed-off-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Reviewed-on: http://openocd.zylin.com/1497
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Factor out common bit masking and printing code and use intermediate
strings to avoid buffer size handling.
Change-Id: I7d8c12df11ade6cdca8c917b5524372daa498bf4
Signed-off-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Reviewed-on: http://openocd.zylin.com/1496
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
These chips are capable of reading the flash registers while they're
running.
Change-Id: I76b90b2bae1aa79b5a063b2073faa5d3ed93cfd7
Signed-off-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Reviewed-on: http://openocd.zylin.com/1495
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
The device was correctly used in stm32lx_probe but missing from stm32lx_get_info.
Change-Id: If288b8df3210a945e727e4e27cfbdb948db32fc7
Signed-off-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-on: http://openocd.zylin.com/1491
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Tested-by: jenkins
This fixes an issue if the device is manually probed after the initial probe
fails due to being unable to read flash size register. In this situation the
driver assumes the user has overridden the flash size when infact this may
not be the case.
It also seems on the older stm32f1 devices the flash register is not readable
when locked, this does not seem to apply to the newer parts - f0, f3, f4.
Change-Id: I125f872fcb2d962ca6705f97b62d957e2b31303b
Signed-off-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-on: http://openocd.zylin.com/1187
Tested-by: jenkins
Reviewed-by: Johan Almquist <johan.almquist@assaabloy.com>
Reviewed-by: Freddie Chopin <freddie.chopin@gmail.com>
Added support for new ST devices in the stm32lx portfolio, with device
id 0x427. These have 256k flash, but in a single bank compared to
device id 0x436 which is a dual bank flash.
Change-Id: Iafdfe990f24bd04b0d6e00385ee70690f3bf8d5f
Signed-off-by: Johan Almquist <johan.almquist@assaabloy.com>
Reviewed-on: http://openocd.zylin.com/1140
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
This update adds support for the STM32Lx 384kb dual bank flash. Previously there was a problem when writing an
image that was larger than 192Kb. That lead to openocd printing out two error messages like
"Error: access denied / write protected" and "Error: invalid program address". The reason was that the stm32lx
driver tried to write half pages which overlapped into the next flash bank.
A new configuration file stm32lx_dual_bank.cfg can be used for stm32lx chips with dual bank flash (256kb or 384kb devices).
A sanity check was added for probed flash size values to fix the issue seen on some ST samples that answered incorrectly.
Change-Id: I69e25131983d88613be8606b438f98870c5f1e52
Signed-off-by: Johan Almquist <johan.almquist@assaabloy.com>
Reviewed-on: http://openocd.zylin.com/1125
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
It has been seen on some stm32 targets that the flash size register that
is probed by the driver may contain an invalid size.
This change enables the user to override the probed value.
Change-Id: I09359e59a96f9133d3d939670957d32a830a944e
Signed-off-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-on: http://openocd.zylin.com/1132
Tested-by: jenkins
Reviewed-by: Johan Almquist <johan.almquist@assaabloy.com>
This makes sure we are using privileged mode when executing any loaders.
Change-Id: I18bf32ec92e1c76a66ab25e3712652bc3650b332
Signed-off-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-on: http://openocd.zylin.com/1108
Tested-by: jenkins
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
To simplify things change over to using the generic core_mode struct rather
than maintaining a armv7m specific one.
Change-Id: Ibf32b785d896fef4f33307fabe0d8eb266f7086f
Signed-off-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-on: http://openocd.zylin.com/966
Tested-by: jenkins
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
An issue has been seen with the stm32lx flash driver that if a
power cycle/reset is applied after a erase, any ram loader will Hard Fault
on execution.
A similar issue is mentioned in the errata for the device.
Two solution's seem to workaround this issue:
1, Handle the exception, this means adding exception vectors to the loader
and changing the exception address using nvic vtor register.
2. falling back to using slower direct page writes - approx 50% slower.
Using solution 1 would mean restrictions are placed on the loader location.
Solution 2 was chosen mainly as it was simpler too implement.
Change-Id: I429f06b5a3e3b1d8de90071a88a7df11fc9b46a7
Signed-off-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-on: http://openocd.zylin.com/1010
Tested-by: jenkins
Waiting 20secs is a bit much excessive, we could probably reduce to 5.
Change-Id: Iffb97adb99c2541a075fe78dbc88a53ddf340214
Signed-off-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-on: http://openocd.zylin.com/1009
Tested-by: jenkins
Handle any leading bytes upto the next 128 byte page, enabling us to safely
use the faster page write.
Rather than use a separate word/byte write to program any trailing bytes
we use a combined write function.
Use memcpy for byte writes and change loader to using bytes.
Change-Id: Ie0164a30388f018dd00e752cf5ff87d4f96ced97
Signed-off-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-on: http://openocd.zylin.com/1008
Tested-by: jenkins
The current stm32lx driver will fail if no working area is
provided - fallback to using slow writes if this is the case.
Change-Id: I92b1535fec4aebc855c63ce2c54b10f168f3c07e
Signed-off-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-on: http://openocd.zylin.com/1007
Tested-by: jenkins
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>