The final erase_mass command check is looking for the EOP (End of
OPeration) bit to be set. This bit is only set when the EOP interrupts
(EOPIE = 1) are enabled. We are not enabling those on the target so this
bit will never get set. As we are monitoring the BSY flag to make sure
the erase_mass operation is still ongoing and finished it is enough if
we just check the error flags.
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>
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.
Option bytes are not accessible with level 1 protection, so
Use FLASH_OPTCR(x)
Fix crash with "mon opt write xxxx"
Handle option manipulation better when HW Watchdog fuse is set
Allow abbreviated "mon option x<yyy>" commands
-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
This way swdp_scan and jtag_scan commands will show the chip that was
detected instead of the generic STM32F4 string. The generic name is
most confusing when attaching to an STM32F7 target.
