A sleeping target continues to communicate over SWD properly but
consistently returns SWDP_ACK_WAIT.
It might be nice to be able to wait for the target to wake up on its
own but if it's not going to wake up, BMP becomes absolutely
unresponsive. Probably the timeout should be made configurable or some
other workaround invented.
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
This implements special handling for SYS_OPEN to catch requests for
":tt" which is reserved by ARM for console input/output. They're
mapped to the appropriate GDB file descriptors automatically.
An additional file handle offset is introduced because ARM doesn't
consider zero handle to be valid.
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Implement bare minimum necessary to support console IO.
This works with standard newlib builds and is based on the reference
documentation:
http://infocenter.arm.com/help/topic/com.arm.doc.dui0471c/CHDJHHDI.html
Tested using gcc-arm-none-eabi-4_7-2013q1-20130313 for both
stm32f1-based BMP and stm32f0 target.
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
This patch introduces a new command, "connect_srst [enable|disable]"
which allows to enable special mode in which SRST would be pulled low
before the SWD scan till attaching to a target.
Since on Cortex-Mx the SRST signal doesn't gate JTAG and SWD, it's
possible to connect to a target while holding reset, ask it to stop at
reset vector and only then deassert reset, thus allowing to attach to
the kind of firmware that goes immediately to sleep or disables
debugging by other means early on start.
Tested on an STM32VLDiscovery board with STM32F100 configured to go to
STOP mode and executing WFI in the very beginning of main().
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
With gcc-arm-none-eabi-4_7-2013q1-20130313 and -O2 I get
text data bss dec hex filename
45744 304 2376 48424 bd28 blackmagic
With -Os the results are even more impressive:
text data bss dec hex filename
37900 304 2376 40580 9e84 blackmagic
Since -Os might lower the debugging speed, do not enable it yet in the
absence of real measurements.
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
The introduction of the double buffering broke USB flow control, causing
loss of data when a new packet arrived with the previous still present in
the double buffer.
With this patch the endpoint is kept in NAK until the double buffer is empty.
Gareth McMullin
Paul Fertser
Gareth McMullin
Allen Ibara
Uwe Bonnes
Vegard Storheil Eriksen