The new Microchip (former Atmel) series powered by Cortex-M4 looks
very similar to older M0+ powered SAM D2x at the first sight.
Unfortunately the new series differs a lot in important details.
NVMCTRL has different register addresses, moved important bits
and even changed binary command set. An universal driver for all SAM D/E
would be very complicated. That's why a new driver was derived.
Tested on Microchip SAM E54 Xplained Pro kit (board cfg included).
Adjusted for the restructured dap support.
Checked by valgrind and clang static analyzer.
Change-Id: I26c67047a552076f4b207b9b89285a53d69b4ca4
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: http://openocd.zylin.com/4272
Tested-by: jenkins
Reviewed-by: Andres Vahter <andres.vahter@gmail.com>
- add 'dap create' command to create dap instances
- move all dap subcmmand into the dap instance commands
- keep 'dap info' for convenience
- change all armv7 and armv8 targets to take a dap
instance instead of a jtag chain position
- restructure tap/dap/target relations, jtag tap no
longer references the dap, daps are now independently
created and initialized.
- clean up swd connect
- re-initialize DAP also on JTAG errors (e.g. after reset,
power cycle)
- update documentation
- update target files
Change-Id: I322cf3969b5407c25d1d3962f9d9b9bc1df067d9
Signed-off-by: Matthias Welwarsky <matthias.welwarsky@sysgo.com>
Reviewed-on: http://openocd.zylin.com/4468
Tested-by: jenkins
Reviewed-by: Matthias Welwarsky <matthias@welwarsky.de>
Commit 25d7ba19c9 introduced a problem
with 'reset halt' due to setting srst_pulls_trst:
Error: cortex_m.c:595 cortex_m_halt(): can't request a halt while
in reset if nSRST pulls nTRST
Sorry, I don't know why I overlooked it when I tested #3722.
Change-Id: I41e9473dd91a86d93cf3e78b1fbbdfe1dd188d83
Reported-by: Ladislav Laska <laska@kam.mff.cuni.cz>
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: http://openocd.zylin.com/3942
Tested-by: jenkins
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Remove comment about workaround of not working 'reset halt' - not needed
as 'reset halt' is working as expected @ EDBG with srst_only.
Add srst_pulls_trst to reset_config as it no more triggers an error.
Change-Id: I47cf445690c46ccfb866900cddbfcaefc8649f82
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: http://openocd.zylin.com/3722
Tested-by: jenkins
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
It's Cortex-Xn, not Cortex Xn or cortex xn or cortex-xn or CORTEX-Xn
or CortexXn. Further it's Cortex-M0+, not M0plus.
Cf. http://www.arm.com/products/processors/index.php
Consistently write it the official way, so that it stops propagating.
Originally spotted in the documentation, it mainly affects code comments
but also Atmel SAM3/SAM4/SAMV, NiietCM4 and SiM3x flash driver output.
Found via:
git grep -i "Cortex "
git grep -i "Cortex-" | grep -v "Cortex-" | grep -v ".cpu"
git grep -i "CortexM"
Change-Id: Ic7b6ca85253e027f6f0f751c628d1a2a391fe914
Signed-off-by: Andreas Färber <afaerber@suse.de>
Reviewed-on: http://openocd.zylin.com/3483
Tested-by: jenkins
Reviewed-by: Marc Schink <openocd-dev@marcschink.de>
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Atmel introduced a "Device Service Unit" (DSU) that holds the CPU
in reset if TCK is low when srst (RESET_N) is deasserted.
Function is similar to SMAP in ATSAM4L, see http://openocd.zylin.com/2604
Atmel's EDBG adapter handles DSU reset correctly without this change.
An ordinary SWD adapter leaves TCK in its default state, low.
So without this change any use of sysresetreq or srst
locks the chip in reset state until power is cycled.
A new function dsu_reset_deassert is called as reset-deassert-post event handler.
It optionally prepares reset vector catch and DSU reset is released then.
Additionally SWD clock comment is fixed in at91samdXX.cfg and clock is
lowered a bit to ensure a margin for RC oscillator frequency deviation.
adapter_nsrst_delay 100 is commented out because is no more necessary after
http://openocd.zylin.com/2601
Change-Id: I42e99b1b245f766616c0a0d939f60612c29bd16c
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: http://openocd.zylin.com/2778
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
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>
This adds a new NOR Flash driver, "at91samd", which supports the
built-in Flash on Atmel's D-series Cortex M MCUs, starting with the D20.
Parts and their geometry are detected automatically using the DSU and
lookup schemes described in the D20 document, 42129F–SAM–10/2013.
Future D-series variants and families should presumably use this
controller as well (possibly with minor changes and improvements).
Tested on the SAMD20 Xplained Pro board, for which we also add the
corresponding Flash configuration.
Change-Id: Id8d3dd601e9f53121682d1a1190d0be4ea3b83eb
Signed-off-by: Andrey Yurovsky <yurovsky@gmail.com>
Reviewed-on: http://openocd.zylin.com/1684
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
These kits feature a CMSIS-DAP compliant debugger and so have been added
as part of the pending support.
Currently the flash drivers for the L8 and D20 are wip.
One issue this implementation of CMSIS-DAP raised is that it supports
512byte HID reports, however using the current HIDAPI we have no cross platform
way of querying this info. Long term we plan to add this support to HIDAPI.
Change-Id: Ie8b7c871f58a099d963cd71a9f8a0105a38784e9
Signed-off-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-on: http://openocd.zylin.com/1625
Tested-by: jenkins
Rename cortex_m3 target to use a more correct cortex_m name.
This also adds a deprecated_name var so that older scripts issue a warning
to update the target name.
cfg files have also been updated to the new target name.
Change-Id: Ia8429f38e88da677249c5caa560c50f8ce56ea10
Signed-off-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-on: http://openocd.zylin.com/1129
Tested-by: jenkins
Reviewed-by: Freddie Chopin <freddie.chopin@gmail.com>
If the target supports SYSRESETREQ make sure we use that as the default
if srst is not fitted/configured.
Change-Id: I24c907493134506320e69c1218702930629c1cdc
Signed-off-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-on: http://openocd.zylin.com/792
Tested-by: jenkins
Reviewed-by: Freddie Chopin <freddie.chopin@gmail.com>
Atmel introduced 6 new Cortex-M4 processors on 2011-10-26
SAM4S16C - 1024KB flash LQFP100/BGA100
SAM4S16B - 1024KB flash LQFP64/QFN64
SAM4S16A - 1024KB flash LQFP48/QFN48
SAM4S8C - 512KB flash LQFP100/BGA100
SAM4S8B - 512KB flash LQFP64/QFN64
SAM4S8A - 512KB flash LQFP48/QFN48
The SAM4S processors still suffer from the "6 waitstates needed
to program device" errata.
Other relevant changes are:
1. Address of flash memory starts at 0x400000.
2. EWP (Erase page and write page) only works for the first two 8KB "sectors"
3. Because of the EWP not working for all the sectors, normal page writes have
to be used. The default_flash_blank_check is used to check if lockregions
should be erased.
4. The EA (Erase All) command takes 7.3s to complete. (Previous timeout was
500 ms)
5. There are 128 lockable regions of 8KB each.
Implemented default blank checking, and page erase for load_image scenarios.
This is to compensate for the EWP flash commands only working on the
first 2 8KB sectors.
Change-Id: I7c5a52b177f7849a107611fd0f635fc416cfb724
Signed-off-by: Olivier Schonken <olivier.schonken@gmail.com>
Reviewed-on: http://openocd.zylin.com/528
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
The SAM3A/X processors that were released thus far is either
a SAM3A/X(4) - 256K, or a SAM3A/X(8) - 512K device. Thus
the config files are per variant, and not per device.
Signed-off-by: Olivier Schonken <olivier.schonken@gmail.com>
Change-Id: I84d26d044e810eb428b1d6287907ea3bf8364c73
Signed-off-by: Olivier Schonken <olivier.schonken@gmail.com>
Reviewed-on: http://openocd.zylin.com/522
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
This affects all configurations including target/at91sam3XXX.cfg
Change-Id: I2c1e1edf0986d30e63f109604a38bf402ded369e
Signed-off-by: Ulf Samuelsson <ulf@emagii.com>
Reviewed-on: http://openocd.zylin.com/292
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Drop useless double-space occurences, drop trailing whitespace, and fix
some other minor whitespace-related issues.
Change-Id: I6b4c515492e2ee94dc25ef1fe4f51015a4bba8b5
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Signed-off-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-on: http://openocd.zylin.com/137
Tested-by: jenkins
General rule, this is all board-specific and doesn't belong
in target config files. Some of these were just cosmetic.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
The semantics of "-work-area-virt 0" (or phys) changed with
the patch to require specifying physical or virtrual work
area addresses. Specifying zero was previously a NOP. Now
it means that address zero is valid.
This patch addresses three related issues:
- MMU-less processors should never specify work-area-virt;
remove those specifications. Such processors include
ARM7TDMI, Cortex-M3, and ARM966.
- MMU-equipped processors *can* specify work-area-virt...
but zero won't be appropriate, except in mischievous
contexts (which hide null pointer exceptions).
Remove those specs from those processors too. If any of
those mappings is valid, someone will need to submit a
patch adding it ... along with a comment saying what OS
provides the mapping, and in which context. Example,
say "works with Linux 2.6.30+, in kernel mode". (Note
that ARM Linux doesn't map kernel memory to zero ...)
- Clarify docs on that "-virt" and other work area stuff.
Seems to me work-area-virt is quite problematic; not every
operating system provides such static mappings; if they do,
they're not in every MMU context...
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Antonio Borneo
Tomas Vanek
Matthias Welwarsky
Andreas Färber
Paul Fertser
Andrey Yurovsky
Spencer Oliver
Olivier Schonken
Ulf Samuelsson
Uwe Hermann
Olaf Lüke
David Brownell
oharboe
dbrownell
zwelch
duane