Connection to USB Freezing #30

Closed
vaibhav-kapoor opened this Issue Nov 16, 2011 · 9 comments

Comments

Projects
None yet
4 participants
@vaibhav-kapoor

vaibhav-kapoor commented Nov 16, 2011

Hi, just wanted to mention really appreciate all the work you guys are doing.

I am running Fedora 16, and having incredible issues getting stm32f4discovery board working consistently.
I was able to get ./st-util working and was able to load the code, but very quickly the microcontroller stops responding. This is the output on the st-util:

[!] send_recv
libusb_submit_transfer(-6)
[!] send_recv
libusb_submit_transfer(-6)
[!] send_recv
libusb_submit_transfer(-6)
[!] send_recv
libusb_submit_transfer(-6)

This occurs continuously, I can't stop the st-util process at all, no matter what I do. The continue command in gdb always hangs the st-util. It is an uninterruptable process. And the only way to fix it is to restart the computer. I couldn't find any way to the get it working without restarting the entire computer. GDB consistently hangs. I seem to get flash working relatively well, it doesn't hang to to much, but it happens after a while. I am having a bit of a tough time figuring everything out, but this is making things far more difficult.

If I disconnect the board and reconnect it the LED close to USB blinks RED. A lot of the issues I can't seem to find info on anywhere, it doesn't looks like its a typical problem. Any help is really appreciated.

Also I noticed the makefiles for all the libraries on the recent update. I really appreciate this as well, for the last couple days I was working on getting the makefiles for the libraries, I had just finished gotten it working, but I can just use yours now.

Again thanks for the help.
TheLegace

@jnosky

This comment has been minimized.

Show comment Hide comment
@jnosky

jnosky Nov 16, 2011

Contributor

CTRL-C might break out of the server.
Try reading and writing to flash with flash.exe.
Have you run the test_usb.exe ? Any problems?
Does the stlink build all build without any error messages?

Contributor

jnosky commented Nov 16, 2011

CTRL-C might break out of the server.
Try reading and writing to flash with flash.exe.
Have you run the test_usb.exe ? Any problems?
Does the stlink build all build without any error messages?

@vaibhav-kapoor

This comment has been minimized.

Show comment Hide comment
@vaibhav-kapoor

vaibhav-kapoor Nov 16, 2011

Everything works at least once, before it get's stuck. Like I said I have explored every way to kill the process, CTRL+C doesn't work, I have tried sending back every possible kill signal, but the process refuses to die.

I will give test_usb a shot, but it's not like nothing works, it just stops working after a while. Flash is working for some time, and stlink builds perfectly.

Everything works at least once, before it get's stuck. Like I said I have explored every way to kill the process, CTRL+C doesn't work, I have tried sending back every possible kill signal, but the process refuses to die.

I will give test_usb a shot, but it's not like nothing works, it just stops working after a while. Flash is working for some time, and stlink builds perfectly.

@vaibhav-kapoor

This comment has been minimized.

Show comment Hide comment
@vaibhav-kapoor

vaibhav-kapoor Nov 16, 2011

This is my test_usb output:

-- version
mode before doing anything: 2
-- enter_swd_mode
-- mode after entering swd mode: 2
-- chip id: 0x413
-- core_id: 0x2ba01477
cpuid:impl_id = 0x41, variant = 0
cpuid:part = 0xc24, rev = 0x1
-- read_sram
FP_CTRL
-- status
-- reset
-- status
-- step
-- run
-- exit_debug_mode

This is my test_usb output:

-- version
mode before doing anything: 2
-- enter_swd_mode
-- mode after entering swd mode: 2
-- chip id: 0x413
-- core_id: 0x2ba01477
cpuid:impl_id = 0x41, variant = 0
cpuid:part = 0xc24, rev = 0x1
-- read_sram
FP_CTRL
-- status
-- reset
-- status
-- step
-- run
-- exit_debug_mode

@vaibhav-kapoor

This comment has been minimized.

Show comment Hide comment
@vaibhav-kapoor

vaibhav-kapoor Nov 16, 2011

One more thing is there anyway I can either restart the entire USB service/driver or something that way it's as if I rebooted the computer but only for the USB. Honestly I love Linux for the fact that I don't have to restart, so I am really hating having to restart.

I just tried writing the discovery project in your update, it writes, but since the file is relatively big it fails, here is output using write:

2011-11-16T12:26:20 DEBUG src/stlink-common.c: *** stlink_read_mem32 ***
libusb_submit_transfer(-6)
[!] send_recv
2011-11-16T12:26:20 DEBUG src/stlink-common.c: *** stlink_read_mem32 ***
libusb_submit_transfer(-6)
[!] send_recv
2011-11-16T12:26:20 DEBUG src/stlink-common.c: *** stlink_read_mem32 ***
libusb_submit_transfer(-6)
[!] send_recv
2011-11-16T12:26:20 DEBUG src/stlink-common.c: *** stlink_read_mem32 ***
libusb_submit_transfer(-6)
[!] send_recv
2011-11-16T12:26:20 DEBUG src/stlink-common.c: *** stlink_read_mem32 ***
libusb_submit_transfer(-6)
[!] send_recv
2011-11-16T12:26:20 DEBUG src/stlink-common.c: *** stlink_read_mem32 ***
libusb_submit_transfer(-6)
[!] send_recv
2011-11-16T12:26:20 DEBUG src/stlink-common.c: *** stlink_read_mem32 ***

test_usb outputs nothing when the thing is frozen, it just hangs.

One more thing is there anyway I can either restart the entire USB service/driver or something that way it's as if I rebooted the computer but only for the USB. Honestly I love Linux for the fact that I don't have to restart, so I am really hating having to restart.

I just tried writing the discovery project in your update, it writes, but since the file is relatively big it fails, here is output using write:

2011-11-16T12:26:20 DEBUG src/stlink-common.c: *** stlink_read_mem32 ***
libusb_submit_transfer(-6)
[!] send_recv
2011-11-16T12:26:20 DEBUG src/stlink-common.c: *** stlink_read_mem32 ***
libusb_submit_transfer(-6)
[!] send_recv
2011-11-16T12:26:20 DEBUG src/stlink-common.c: *** stlink_read_mem32 ***
libusb_submit_transfer(-6)
[!] send_recv
2011-11-16T12:26:20 DEBUG src/stlink-common.c: *** stlink_read_mem32 ***
libusb_submit_transfer(-6)
[!] send_recv
2011-11-16T12:26:20 DEBUG src/stlink-common.c: *** stlink_read_mem32 ***
libusb_submit_transfer(-6)
[!] send_recv
2011-11-16T12:26:20 DEBUG src/stlink-common.c: *** stlink_read_mem32 ***
libusb_submit_transfer(-6)
[!] send_recv
2011-11-16T12:26:20 DEBUG src/stlink-common.c: *** stlink_read_mem32 ***

test_usb outputs nothing when the thing is frozen, it just hangs.

@vaibhav-kapoor

This comment has been minimized.

Show comment Hide comment
@vaibhav-kapoor

vaibhav-kapoor Nov 18, 2011

I don't know if this helps, but once the libusb freezes, and I disconnect the device and do lsusb, the Bus 003 Device 003: ID 0483:3748 SGS Thomson Microelectronics doesn't disappear, which is totally weird.

Here is some more info if you would like:

Bus 003 Device 003: ID 0483:3748 SGS Thomson Microelectronics
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x0483 SGS Thomson Microelectronics
idProduct 0x3748
bcdDevice 1.00
iManufacturer 1 STMicroelectronics
iProduct 2 STM32 STLink
iSerial 3 Q�kH�IS'�
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 39
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 4 ST Link
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x0000
(Bus Powered)

I think both flash, and st-util end up becoming a zombie process. I will test with other distro, but I'm sure it's a kernel issue, but no one else seems to be having trouble. I am assuming your not.

Thanks for everything.

I don't know if this helps, but once the libusb freezes, and I disconnect the device and do lsusb, the Bus 003 Device 003: ID 0483:3748 SGS Thomson Microelectronics doesn't disappear, which is totally weird.

Here is some more info if you would like:

Bus 003 Device 003: ID 0483:3748 SGS Thomson Microelectronics
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x0483 SGS Thomson Microelectronics
idProduct 0x3748
bcdDevice 1.00
iManufacturer 1 STMicroelectronics
iProduct 2 STM32 STLink
iSerial 3 Q�kH�IS'�
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 39
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 4 ST Link
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x0000
(Bus Powered)

I think both flash, and st-util end up becoming a zombie process. I will test with other distro, but I'm sure it's a kernel issue, but no one else seems to be having trouble. I am assuming your not.

Thanks for everything.

@vaibhav-kapoor

This comment has been minimized.

Show comment Hide comment
@vaibhav-kapoor

vaibhav-kapoor Nov 23, 2011

After going through distro after distro, I manged to figure out that this looks like a either a Fedora 16 problem, or a newer kernel issue.
I was able to successfully use your program without any hiccups or problems in Ubuntu 11.04. I don't remember the specifics, but if you want me to do any testing feel free to ask.
Thanks.

After going through distro after distro, I manged to figure out that this looks like a either a Fedora 16 problem, or a newer kernel issue.
I was able to successfully use your program without any hiccups or problems in Ubuntu 11.04. I don't remember the specifics, but if you want me to do any testing feel free to ask.
Thanks.

@karlp

This comment has been minimized.

Show comment Hide comment
@karlp

karlp Nov 23, 2011

Contributor

I bet this is the same as #31

Looks like the USB isn't getting cleaned up properly in certain exit cases, and restarting the app doesn't clean it up either. Having a bit of a look at a proper fix

Contributor

karlp commented Nov 23, 2011

I bet this is the same as #31

Looks like the USB isn't getting cleaned up properly in certain exit cases, and restarting the app doesn't clean it up either. Having a bit of a look at a proper fix

@vaibhav-kapoor

This comment has been minimized.

Show comment Hide comment
@vaibhav-kapoor

vaibhav-kapoor Nov 25, 2011

When I get some time after my exams I will try and help out with the project and fix the bug (not a fan of ubuntu). Are you running latest kernel? We could also try and compare libusb versions.

On the working Ubuntu I have is 1.0.8-2.

Oh also, if you ever get a chance and update the write program could add a command that resets the microcontroller. I don't know if it's normal, but after writing I have to power cycle the stm32f4 board and my program starts running.

Thanks appreciate it.

When I get some time after my exams I will try and help out with the project and fix the bug (not a fan of ubuntu). Are you running latest kernel? We could also try and compare libusb versions.

On the working Ubuntu I have is 1.0.8-2.

Oh also, if you ever get a chance and update the write program could add a command that resets the microcontroller. I don't know if it's normal, but after writing I have to power cycle the stm32f4 board and my program starts running.

Thanks appreciate it.

@xor-gate

This comment has been minimized.

Show comment Hide comment
@xor-gate

xor-gate May 17, 2016

Collaborator

Please test against v1.2.0 or master, because this issue references a very old version of the stlink tools. Feel free to open a new issue if the problem still remains.

Collaborator

xor-gate commented May 17, 2016

Please test against v1.2.0 or master, because this issue references a very old version of the stlink tools. Feel free to open a new issue if the problem still remains.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment