Closed canatella closed 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?
Thank you for the example, it is indeed working if I do a monitor swdp_scan again :) Closing this.
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.
What firmware?
I just reflashed with master to be sure and I have the same behaviour (I'm on macos).
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
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?
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...
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.
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!
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.
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