The datasheet specifies the EEFC_BASE(0) is at `0x400E0A00` and EEFC_BASE(1) is at `0x400E0C00` which means they're spaced 0x200 bytes apart rather than 0x400.
this fixes a bug that was introduced in blackmagic PR #475 which lead to
firmware crashes when connecting to a BMP more than once without a
power-cycle.
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.
Uwe Bonnes
Stephen Roe
Simon Rasmussen
David R. Piegdon
Sid Price
Richard Meadows
Jeremy Elson
Boris Sorochkin
newbrain
anyn99
Carl