Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Nucleo-F401RE: Communication hangs after a while #225

Closed
fhars opened this issue Apr 21, 2014 · 3 comments · Fixed by #374
Closed

Nucleo-F401RE: Communication hangs after a while #225

fhars opened this issue Apr 21, 2014 · 3 comments · Fixed by #374
Labels
component/st-util dependency/libusb os/linux status/resolved target/stm32f4
Milestone
v1.2.0 and older

Comments

@fhars
Copy link
Contributor

fhars commented Apr 21, 2014

After a while, communication between st-util and my nucleo board fails.

It starts just fine, I can load a program and run it and use gdb on it as expected. Verbose output during this phase looks like:

2014-04-21T19:45:04 DEBUG src/stlink-common.c: stlink current mode: mass
2014-04-21T19:45:04 DEBUG src/stlink-common.c: stlink current mode: mass
2014-04-21T19:45:04 DEBUG src/stlink-common.c: *** stlink_enter_swd_mode ***
2014-04-21T19:45:04 INFO src/stlink-common.c: Loading device parameters....
2014-04-21T19:45:04 DEBUG src/stlink-common.c: *** stlink_core_id ***
2014-04-21T19:45:04 DEBUG src/stlink-common.c: core_id = 0x2ba01477
2014-04-21T19:45:04 DEBUG src/stlink-common.c: *** stlink_read_debug32 10006433 is 0xe0042000
2014-04-21T19:45:04 DEBUG src/stlink-common.c: *** stlink_read_debug32 200c000 is 0x1fff7a20
2014-04-21T19:45:04 INFO src/stlink-common.c: Device connected is: F4 device (Dynamic Efficency), id 0x10006433
2014-04-21T19:45:04 INFO src/stlink-common.c: SRAM size: 0x18000 bytes (96 KiB), Flash: 0x80000 bytes (512 KiB) in pages of 16384 bytes
2014-04-21T19:45:04 DEBUG src/stlink-common.c: *** looking up stlink version
2014-04-21T19:45:04 DEBUG src/stlink-common.c: st vid         = 0x0483 (expect 0x0483)
2014-04-21T19:45:04 DEBUG src/stlink-common.c: stlink pid     = 0x374b
2014-04-21T19:45:04 DEBUG src/stlink-common.c: stlink version = 0x2
2014-04-21T19:45:04 DEBUG src/stlink-common.c: jtag version   = 0x13
2014-04-21T19:45:04 DEBUG src/stlink-common.c: swim version   = 0x2
2014-04-21T19:45:04 DEBUG src/stlink-common.c: *** stlink_reset ***
2014-04-21T19:45:04 DEBUG src/stlink-common.c: *** reading target voltage
2014-04-21T19:45:04 DEBUG src/stlink-common.c: target voltage = 3246mV
2014-04-21T19:45:21 DEBUG src/stlink-common.c: *** stlink_force_debug_mode ***
2014-04-21T19:45:21 DEBUG src/stlink-common.c: *** stlink_reset ***
2014-04-21T19:45:21 DEBUG src/stlink-common.c: *** stlink_write_debug32 3 to 0xe0002000
2014-04-21T19:45:21 DEBUG src/stlink-common.c: *** stlink_read_debug32 261 is 0xe0002000
2014-04-21T19:45:21 DEBUG src/stlink-common.c: *** stlink_write_debug32 0 to 0xe0002008
2014-04-21T19:45:21 DEBUG src/stlink-common.c: *** stlink_write_debug32 0 to 0xe000200c
2014-04-21T19:45:21 DEBUG src/stlink-common.c: *** stlink_write_debug32 0 to 0xe0002010
2014-04-21T19:45:21 DEBUG src/stlink-common.c: *** stlink_write_debug32 0 to 0xe0002014
2014-04-21T19:45:21 DEBUG src/stlink-common.c: *** stlink_write_debug32 0 to 0xe0002018
2014-04-21T19:45:21 DEBUG src/stlink-common.c: *** stlink_write_debug32 0 to 0xe000201c
2014-04-21T19:45:21 DEBUG src/stlink-common.c: *** stlink_read_debug32 1 is 0xe000edfc
2014-04-21T19:45:21 DEBUG src/stlink-common.c: *** stlink_write_debug32 1000001 to 0xe000edfc
2014-04-21T19:45:21 DEBUG src/stlink-common.c: *** stlink_write_debug32 0 to 0xe0001028
2014-04-21T19:45:21 DEBUG src/stlink-common.c: *** stlink_write_debug32 0 to 0xe0001038
2014-04-21T19:45:21 DEBUG src/stlink-common.c: *** stlink_write_debug32 0 to 0xe0001048
2014-04-21T19:45:21 DEBUG src/stlink-common.c: *** stlink_write_debug32 0 to 0xe0001058
2014-04-21T19:45:22 DEBUG src/stlink-common.c: *** stlink_read_all_regs ***
2014-04-21T19:45:22 DEBUG src/stlink-common.c: *** stlink_read_all_regs ***
2014-04-21T19:45:22 DEBUG src/stlink-common.c: *** stlink_read_mem32 ***
2014-04-21T19:45:22 DEBUG src/stlink-common.c: *** stlink_read_reg
2014-04-21T19:45:22 DEBUG src/stlink-common.c:  (16) ***
2014-04-21T19:45:22 DEBUG src/stlink-usb.c: r_idx (16) = 0x01000000
2014-04-21T19:45:28 DEBUG src/stlink-common.c: *** stlink_run ***
2014-04-21T19:45:28 DEBUG src/stlink-common.c: *** stlink_status ***
2014-04-21T19:45:28 DEBUG src/stlink-common.c:   core status: running
2014-04-21T19:45:28 DEBUG src/stlink-common.c: *** stlink_status ***
2014-04-21T19:45:28 DEBUG src/stlink-common.c:   core status: running
2014-04-21T19:45:28 DEBUG src/stlink-common.c: *** stlink_status ***
2014-04-21T19:45:28 DEBUG src/stlink-common.c:   core status: running
2014-04-21T19:45:28 DEBUG src/stlink-common.c: *** stlink_status ***
2014-04-21T19:45:28 DEBUG src/stlink-common.c:   core status: running
2014-04-21T19:45:29 DEBUG src/stlink-common.c: *** stlink_status ***
2014-04-21T19:45:29 DEBUG src/stlink-common.c:   core status: running
2014-04-21T19:45:29 DEBUG src/stlink-common.c: *** stlink_status ***

The ST-LINK LED blinks red/green to signal ongoing communication.

But then after a while I get:

2014-04-21T19:58:31 DEBUG src/stlink-common.c: *** stlink_status ***
2014-04-21T19:58:31 DEBUG src/stlink-common.c:   core status: running
2014-04-21T19:58:31 DEBUG src/stlink-common.c: *** stlink_status ***
2014-04-21T19:58:31 DEBUG src/stlink-common.c:   core status: running
2014-04-21T19:58:31 DEBUG src/stlink-common.c: *** stlink_status ***
2014-04-21T19:58:31 DEBUG src/stlink-common.c:   core status: running
2014-04-21T19:58:31 DEBUG src/stlink-common.c: *** stlink_status ***
2014-04-21T19:58:31 DEBUG src/stlink-common.c:   core status: running
2014-04-21T19:58:32 DEBUG src/stlink-common.c: *** stlink_status ***
Chip ID is 00000433, Core ID is  2ba01477.
Target voltage is 3246 mV.
Listening at *:4242...
GDB connected.
libusb_handle_events() timeout
[!] send_recv
libusb_handle_events() timeout
[!] send_recv
libusb_submit_transfer(-6)
[!] send_recv
libusb_submit_transfer(-6)
[!] send_recv
libusb_submit_transfer(-6)
[!] send_recv
libusb_submit_transfer(-6)
[!] send_recv
libusb_submit_transfer(-6)

The program on the board continues running, and gdb still thinks it can talk to the server, but it can no longer actually affect the board, the ST-LINK LED swiches to green ("communication finished and successful"). st-util still continues to print the "core status: running" messages.

If I then quit st-util with Ctrl-C and restart it, I get:

2014-04-21T20:20:48 DEBUG src/stlink-common.c: stlink mode: unknown!
2014-04-21T20:20:48 DEBUG src/stlink-common.c: stlink mode: unknown!
2014-04-21T20:20:48 DEBUG src/stlink-common.c: *** stlink_enter_swd_mode ***
2014-04-21T20:20:48 INFO src/stlink-common.c: Loading device parameters....
2014-04-21T20:20:48 DEBUG src/stlink-common.c: *** stlink_core_id ***
2014-04-21T20:20:48 DEBUG src/stlink-common.c: core_id = 0x00000000
2014-04-21T20:20:48 DEBUG src/stlink-common.c: *** stlink_read_debug32 0 is 0xe0042000
2014-04-21T20:20:48 DEBUG src/stlink-common.c: *** stlink_read_debug32 0 is 0x40015800
2014-04-21T20:20:48 WARN src/stlink-common.c: unknown chip id! 0
2014-04-21T20:20:48 DEBUG src/stlink-common.c: *** looking up stlink version
2014-04-21T20:20:48 DEBUG src/stlink-common.c: st vid         = 0x0000 (expect 0x0483)
2014-04-21T20:20:48 DEBUG src/stlink-common.c: stlink pid     = 0x0000
2014-04-21T20:20:48 DEBUG src/stlink-common.c: stlink version = 0x0
2014-04-21T20:20:48 DEBUG src/stlink-common.c: jtag version   = 0x0
2014-04-21T20:20:48 DEBUG src/stlink-common.c: swim version   = 0x0
2014-04-21T20:20:48 DEBUG src/stlink-common.c:     notice: the firmware doesn't support a jtag/swd interface
2014-04-21T20:20:48 DEBUG src/stlink-common.c:     notice: the firmware doesn't support a swim interface
2014-04-21T20:20:48 DEBUG src/stlink-common.c: *** stlink_reset ***
2014-04-21T20:20:48 DEBUG src/stlink-common.c: *** reading target voltage
2014-04-21T20:20:48 DEBUG src/stlink-common.c: error reading target voltage

Powercycling the Nucleo board puts it in a usable state again.
@fhars fhars changed the title Communicatin with Nucleo-F401RE hangs after a while Communication with Nucleo-F401RE hangs after a while Apr 21, 2014
@fhars
Copy link
Contributor Author

fhars commented May 8, 2014

I found a way to reliably kill the connection with the Nucleo: Run a program that writes lots of stuff to USART2 on the Nucleo (which is forwarded as an usb-serial device over the stlink on the board), then read from that usb-serial device on the computer (for example with microcom -p /dev/stlinkv2-1_1). After a few lines of output, I get the libusb timeouts, and if I then kill st-util with Ctrc-C I get a segfault in

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f7b5cd54d4a in ?? () from /lib/x86_64-linux-gnu/libusb-1.0.so.0
(gdb) bt
#0  0x00007f7b5cd54d4a in ?? () from /lib/x86_64-linux-gnu/libusb-1.0.so.0
#1  0x00007f7b5cd54f40 in libusb_close () from /lib/x86_64-linux-gnu/libusb-1.0.so.0
#2  0x00000000004073a4 in _stlink_usb_close (sl=<optimized out>) at src/stlink-usb.c:46
#3  0x00000000004041c2 in stlink_close (sl=0x9a4010) at src/stlink-common.c:372
#4  0x00000000004022ed in cleanup (signal=<optimized out>) at gdbserver/gdb-server.c:63
#5  <signal handler called>
#6  0x00007f7b5ca49d7d in nanosleep () at ../sysdeps/unix/syscall-template.S:81
#7  0x00007f7b5ca7b334 in usleep (useconds=useconds@entry=100000) at ../sysdeps/unix/sysv/linux/usleep.c:32
#8  0x00000000004033db in serve (sl=sl@entry=0x9a4010, st=st@entry=0x7fffa75b2600) at gdbserver/gdb-server.c:976
#9  0x0000000000401e33 in main (argc=<optimized out>, argv=<optimized out>) at gdbserver/gdb-server.c:217

(I have not yet updated the firmware on the nucleo for want of a windows machine so the cause of the hangup may be a bug there, but a segfault is usally a bug in the segfaulting program).

@xor-gate
Copy link
Member

xor-gate commented May 4, 2016

Please test against latest stlink master tools, and latest ST programmer firmware. Reopen a new issue when the problem still remains.

@xor-gate xor-gate closed this as completed May 4, 2016
@Nightwalker-87 Nightwalker-87 added this to the Feedback required milestone Feb 26, 2020
@Nightwalker-87 Nightwalker-87 changed the title Communication with Nucleo-F401RE hangs after a while Nucleo-F401RE: Communication hangs after a while Apr 3, 2020
@Nightwalker-87 Nightwalker-87 modified the milestones: Feedback required, Device issues, USB connection issues Apr 3, 2020
@Nightwalker-87 Nightwalker-87 modified the milestones: d) USB connection issues (libusb), a) Old issues Mar 11, 2021
@stlink-org stlink-org deleted a comment from chenguokai Mar 21, 2021
@Nightwalker-87 Nightwalker-87 linked a pull request Mar 21, 2021 that will close this issue
use libusb synchronous api #374
Merged
@Nightwalker-87 Nightwalker-87 modified the milestones: Old issues, v1.2.0 and older Mar 21, 2021
@Nightwalker-87
Copy link
Member

This problem is similar to a previously observed issue in #194.
The observed behaviour could have resulted from a faulty libusb implementation (what is the primary expectation).
Nevertheless a firmware issue in the programmer may have also resulted in the corrupted USB connection.
gdb should indeed be able to detect a connection loss to the server.
However, as it is a stand-alone tool, this partial aspect is not related to the stlink toolset.

As the toolset-related issue has been addressed and one can safely assume that this is also the case for the aspects that derive from external tools, I am finally closing this issue now as resolved.

@stlink-org stlink-org locked as resolved and limited conversation to collaborators Mar 21, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
component/st-util dependency/libusb os/linux status/resolved target/stm32f4
Projects
None yet
Milestone
v1.2.0 and older
Development

Successfully merging a pull request may close this issue.

use libusb synchronous api gtalusan/stlink
3 participants
@fhars @xor-gate @Nightwalker-87