Restore the RAM and registers which are clobbered by an LPC IAP call.
This does not restore any additional RAM which might be clobbered
by a *particular* IAP call. (For example, flash programming always
clobbers the last page of RAM.)
This commit modifies lpc_iap_call() to work with IAP commands that
return additional data. If the "result" argument is non-null, 16
bytes of data (the maximum returned by any IAP command) are copied
to the specified address.
This is will make debugging earier if this does happen, rather than
dereferencing the null pointer (or passing it to memcpy, or worse).
blackmagic PR #475
* Reference latest version of the ARM specification
* ROM tables - more debug information, including printing SYSMEM bit
* MEM-AP - reject when Debug Base Address entry is not
present/invalid. These would only have errored in
adiv5_component_probe.
* Fix maximum number of entries in Class 0x1 ROM Table to 960. See ARM
IHI 0031E Table D3-1 ROM Table register summary.
* Resolve note in STM32H7 driver with explaination
blackmagic PR #474
When `target_add_flash` or `target_add_ram` are called in an attach
function they may be added multiple times. This very much confuses
GDB. This issue has already been reported and fixed for `stm32l4` (See
Issue #455 ).
`stm32f4` and `stm32l4` are the only other cortexm drivers that
implement this pattern. These are both fine.
* Accept prefixes of the words 'enable' and 'disable'
* Prevent silent failures on parse errors
* Print status after flag changes
* Fix missing includes
Memory map is now completely freed and rebuilt in the separate attach
function.
It was previoulsy split beween probe and attach and never released,
causing problems when reattaching to the same target.
Support for Kinetis KE04 8KiB, 64KiB and 128KiB variants in nxpke04.c
Target monitor commands for sector and mass erase.
Changes to kinetis.c MDM-AP target to support KE04.
Only KE04Z8 tested in HW.
* [efm32] Assume Device Identification (DI) version 1 if we don't know the OUI
Silabs are using some additional OUIs we don't know about. Reported in issue #389
These should use a DI version 1 layout, so assume version 1 layout for OUIs we don't
know. However do print a notice about this on DEBUG() as suggested by @UweBonnes
The IDCODE value is sufficient to make a positive identification of an EFM32 device.
See AN0062 Section 2.2. Therefore accepting any OUI is reasonable behaviour.
Additionally the part familiy is checked, and the target rejected if not in the
`efm32_devices` table. This commit makes that rejection explicit, although it does
not change the logical behaviour here.
Note that the important registers (part number, part family, flash size) are at the
same addresses in both layouts anyhow. Currently only `efm32_cmd_serial` and
`efm32_cmd_efm_info` functions use registers that differ between DI versions.
* [efm32] tidy format warning about portability UB
* [efm32] Simplify OUI checking
* Only read the OUI once
* Accept the device even if the OU is unknown, as silabs have been using
a variety of OUIs
* Perform fewer register reads before checking the device family is valid
Tested with x86_64-w64-mingw32-gcc-8.2.0 and cygwin gcc (GCC) 7.3.0.
Use libftdi1 unconditionally.
Try to convice github travis to use libftdi1.
Remove unportable "uint ". Thanks to jacereda for pointing out in #400.
* Add support for LPC11U3X devices.
The DeviceID register has a different address from the LPC11XX devices.
But it is shared with the LPC8XX family.
* Fix support for LPC1115 and LPC1115XL devices
* Fix whitespace
Alexander Zhang
David Lawrence
Sid Price
Richard Meadows
Uwe Bonnes
Jeremy Elson
Boris Sorochkin
newbrain
anyn99
Carl
Ingmar Jager
Manoel Brunnen
Josh Robson Chase