search

blackmagic-debug / blackmagic

In application debugger for ARM Cortex microcontrollers.
GNU General Public License v3.0
3.2k stars 764 forks source link

Having to unplug/replug usb after detach #728

Closed canatella closed 3 years ago

canatella commented 3 years ago

Hello, is it normal that I have to unplug/replug usb after I detach from a target before I can reconnect ? When detaching the orange led dims and then I need to unplug/replug. I'm on the blackmagic probe v2.1c

UweBonnes commented 3 years ago

arm-none-eabi-gdb ... (gdb) tar ext /dev/ttyACM0 Remote debugging using /dev/ttyACM0 (gdb) mon s Target voltage: 3.3V Available Targets: No. Att Driver 1 STM32L41x M4 (gdb) att 1 Attaching to Remote target warning: No executable has been specified and target does not support determining executable automatically. Try using the "file" command. 0x0800004e in ?? () (gdb) detach Detaching from program: , Remote target [Inferior 1 (Remote target) detached] (gdb) mon s Target voltage: 3.3V Available Targets: No. Att Driver 1 STM32L41x M4 (gdb) att 1 Attaching to Remote target warning: No executable has been specified and target does not support determining executable automatically. Try using the "file" command. 0x0800004e in ?? ()

With detach, the orange LED starts to blink and keeps blinking. That is missleading, but I think what you call reconnect works here.

What target do you have? Can you try with other targets? What is the device state when you need to reconnect on the PC side, is the BMP still visible to the system?

canatella commented 3 years ago

Thank you for the example, it is indeed working if I do a monitor swdp_scan again :) Closing this.

canatella commented 3 years ago

Oups my bad, it what is really not working is exiting gdb and relaunching:

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from cmake-build-nrf52-debug/bin/frontend.elf...
.gdbinit:1: Error in sourced command file:
"monitor" command not supported by this target.
(gdb) tar ext /dev/tty.usbmodemBFC883EC1
Remote debugging using /dev/tty.usbmodemBFC883EC1
(gdb) quit
veygosx-2:sensor-blp dam$ arm-none-eabi-gdb  cmake-build-nrf52-debug/bin/frontend.elf 
GNU gdb (GDB) 8.3.1
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-apple-darwin18.5.0 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from cmake-build-nrf52-debug/bin/frontend.elf...
(gdb) tar ext /dev/tty.usbmodemBFC883EC1

It is stuck there, the serial device is still present. I have an atmel sam4s and a nrf52 target and behaviour is the same on both.

UweBonnes commented 3 years ago

What firmware?

canatella commented 3 years ago

I just reflashed with master to be sure and I have the same behaviour (I'm on macos).

UweBonnes commented 3 years ago

Ah, more basic information. Working on Macos! It seems that "quit" leaves the modem in a state that Macos can not reconnect. Can you try to find out why macos does not find the modem again? Is it still visible as device? On linux , I could sreach for the failing open with "strace -f -o /tmp/log arm-non-eabi-gdb . Perhaps there is something similar in macos. Or if you have a debug version of arm-non-eabi-gdb, debug it with gdb. A look at the gdb sources may also be helpfull.

In the logs I only see related to macos: commit b36242d0219668f939ec5e4e83a39dd68f28f179 Author: Gareth McMullin gareth@blacksphere.co.nz Date: Thu Feb 17 15:06:27 2011 +1300

CDC-ACM now asserts DCD to allow opening tty devs in BSD/MacOS.
Cleaned up compiler warnings.

Did some later commit eventually cause colateral damage to that?

canatella commented 3 years ago

I can reproduce the problem with socat: When everything is ok:

2020/09/17 14:58:46 socat[92567] N opening character device "/dev/tty.usbmodemBFC997F51" for reading and writing
2020/09/17 14:58:46 socat[92567] D open("/dev/tty.usbmodemBFC997F51", 02, 0666)
2020/09/17 14:58:46 socat[92567] I open("/dev/tty.usbmodemBFC997F51", 02, 0666) -> 5
2020/09/17 14:58:46 socat[92567] D isatty(5)
2020/09/17 14:58:46 socat[92567] D isatty() -> 1
2020/09/17 14:58:46 socat[92567] D tcgetattr(5, 0x7fe33a504608)

And when gdb won't connect its is stuck in open:

2020/09/17 14:59:54 socat[92906] N opening character device "/dev/tty.usbmodemBFC997F51" for reading and writing
2020/09/17 14:59:54 socat[92906] D open("/dev/tty.usbmodemBFC997F51", 02, 0666)

Still investigating...

UweBonnes commented 3 years ago

That sounds like a missbehaviour in macos. Even is the usb device is not cooperative or even evil, open should return, best with a sensible error.

canatella commented 3 years ago

Ok nailed it down. Maybe worth a note in the wiki for other newbies like me, on mac os, one needs to use the /dev/cu.usbmodem* device and not the /dev/tty.usbmodem* ones. Thanks for you help, it is much appreciated!

DanielO commented 3 years ago

I can replicate this with bdb351a. I think there must be a bug in OSX since if I use the cu device, then quit GDB and restart and try and use the tty one it says it's busy (even though lsof shows nothing using either device).

tl;dr - use the cu device on OSX (and probably any BSD) and there will be less pain.