It seems, writing to DHCSR fails silent when the device is sleeping.
Reading DHCS during sleep may return nonsense.
Repeated write may at some point catch the device running and succeed.
With devices sleeping for long time and running on faster clock the
chance for a successful hotplug gets smaller.
- Try hard to halt a sleeping device
- Prepare vector catch and enable all debug units by TRACENA
- Release reset
- Apply device specific fixes
-- STM32F7: Store old value of DBGMCU_CR, enable debug in sleep in
DBGMCU before reading PIDR and restore DBGMCU on detach.
Signed-off-by: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
* stm32h7: Don't tc_printf from flash functions
Receving an 'O' packet while flashing confuses GDB and then
weird stuff happens.
* Replace tc_printf with DEBUG_WARN
Firmware BMP with ENABLE_DEBUG=1 will print WARN and INFO as before.
PC-Hosted BMPwill alway print to stderr. Warn is printed unconditional,
INFO, GDB, TARGET, DONGLE and WIRE will print if their appropriate bit in
cl_debuglevel is set via the -v verbose command line argument.
INFO will go to stdout with -t or -l.
-Wall on gcc8 otherwise warns without -Wno-cast-function-type but older
GCCs/CLang choke on that argument:
error: unknown warning option '-Wno-cast-function-type'; did you mean
'-Wno-bad-function-cast'? [-Werror,-Wunknown-warning-option]
This adds 24 byte to the binary, as some functions are now called with
additional dummy arguments:
"Pushing and popping garbage to keep the system happy"
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.
