USB on STM32F3DISCOVERY

ChibiOS public support forum for topics related to the STMicroelectronics STM32 family of micro-controllers.

Moderators: barthess, RoccoMarco

zwhite
Posts: 4
Joined: Mon Jul 17, 2017 5:59 am

USB on STM32F3DISCOVERY

Postby zwhite » Mon Jul 17, 2017 6:42 am

I can't seem to get USB in Chibios working on my STM32F3DISCOVERY board. I'm starting to suspect it's a bug in Chibios and not anything I'm doing.

To start with I can grab cjheath/stm32f3-discovery-usb-example from GitHub, compile and flash it over st-link, and it works fine. Tilting the board moves my mouse cursor around as you'd expect. I can also download ChibiOS_17.6.0 and compile demos/STM32/RT-STM32F303-DISCOVERY and flash it, and the LED's on the compass chase around in a circle.

However, I can't get USB working under Chibios. I've tried compiling ChibiOS_17.6.0/testhal/STM32/STM32F3xx/USB_CDC, which is supposed to work on the stm32f3-discovery, but it doesn't work. I've also tried kernsny/chibios-stm32f3discovery on GitHub, and that project doesn't work either. In both cases I'm simply acquiring the source code, changing into the root directory, running make, and flashing the resulting ch.bin file. These demos target the stm32f3discovery board, and my board is a brand new unit received from digikey yesterday, with no hardware changes made.

From what I can tell usbStart() is called but never returns. Here's an example gdb session:

Code: Select all

zach-desktop:USB_CDC zwhite$ arm-none-eabi-gdb build/ch.elf
GNU gdb (GNU Tools for ARM Embedded Processors 6-2017-q1-update) 7.12.1.20170215-git
Copyright (C) 2017 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-darwin10 --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 build/ch.elf...done.
(gdb) target extended-remote :4242
Remote debugging using :4242
0x080001a0 in Reset_Handler ()
(gdb) load
Loading section .vectors, size 0x1a0 lma 0x8000000
Loading section .text, size 0x9c90 lma 0x80001a0
Loading section .rodata, size 0x1f54 lma 0x8009e30
Loading section .data, size 0x488 lma 0x800bd84
Start address 0x80001a0, load size 49676
Transfer rate: 14 KB/sec, 8279 bytes/write.
(gdb) break usbStart
Breakpoint 1 at 0x800422e: file ../../../../os/common/ext/CMSIS/include/cmsis_gcc.h, line 264.
(gdb) break main.c:143
Breakpoint 2 at 0x80042b8: file main.c, line 143.
(gdb) c
Continuing.
Note: automatically using hardware breakpoints for read-only addresses.

Breakpoint 1, main () at main.c:142
142     usbStart(serusbcfg.usbp, &usbcfg);
(gdb) c
Continuing.


^C
Program received signal SIGTRAP, Trace/breakpoint trap.
0x08002b32 in chSysHalt (reason=reason@entry=0x800a28c "SV#6")
    at ../../../../os/rt/src/chsys.c:200
200     ch.dbg.panic_msg = reason;
(gdb) bt
#0  0x08002b32 in chSysHalt (reason=reason@entry=0x800a28c "SV#6")
    at ../../../../os/rt/src/chsys.c:200
#1  0x080031c4 in _dbg_check_lock_from_isr () at ../../../../os/rt/src/chdebug.c:179
#2  0x08003a76 in chSysLockFromISR () at ../../../../os/rt/include/chsys.h:418
#3  usb_event (usbp=<optimized out>, event=<optimized out>, usbp=<optimized out>)
    at usbcfg.c:291
#4  0x08004298 in usb_lld_start (usbp=0x20001130 <USBD1>)
    at ../../../../os/hal/ports/STM32/LLD/USBv1/hal_usb_lld.c:495
#5  usbStart (config=0x800a4c0 <usbcfg>, usbp=0x20001130 <USBD1>)
    at ../../../../os/hal/src/hal_usb.c:311
#6  main () at main.c:142


This is what I get in the system log when I plug it into a raspberry pi:

Code: Select all

Jul 16 22:24:13 laser-monitor kernel: [538150.971812] usb 1-1.2: new full-speed USB device number 100 using dwc_otg
Jul 16 22:24:14 laser-monitor kernel: [538151.071772] usb 1-1.2: device descriptor read/64, error -32
Jul 16 22:24:14 laser-monitor kernel: [538151.291803] usb 1-1.2: device descriptor read/64, error -32
Jul 16 22:24:14 laser-monitor kernel: [538151.511789] usb 1-1.2: new full-speed USB device number 101 using dwc_otg
Jul 16 22:24:14 laser-monitor kernel: [538151.611828] usb 1-1.2: device descriptor read/64, error -32
Jul 16 22:24:14 laser-monitor kernel: [538151.831791] usb 1-1.2: device descriptor read/64, error -32
Jul 16 22:24:15 laser-monitor kernel: [538152.051832] usb 1-1.2: new full-speed USB device number 102 using dwc_otg
Jul 16 22:24:15 laser-monitor kernel: [538152.491828] usb 1-1.2: device not accepting address 102, error -32
Jul 16 22:24:15 laser-monitor kernel: [538152.591826] usb 1-1.2: new full-speed USB device number 103 using dwc_otg
Jul 16 22:24:16 laser-monitor kernel: [538153.031820] usb 1-1.2: device not accepting address 103, error -32
Jul 16 22:24:16 laser-monitor kernel: [538153.032045] usb 1-1-port2: unable to enumerate USB device


Could something have changed in Chibios since the last time anyone tried these demos?

User avatar
Giovanni
Site Admin
Posts: 10004
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 185 times
Been thanked: 168 times
Contact:

Re: USB on STM32F3DISCOVERY

Postby Giovanni » Mon Jul 17, 2017 7:41 am

Hi,

I will give it a try when back at home, what toolchain are you using?

Giovanni

zwhite
Posts: 4
Joined: Mon Jul 17, 2017 5:59 am

Re: USB on STM32F3DISCOVERY

Postby zwhite » Mon Jul 17, 2017 2:13 pm

Thanks Giovanni. I'm using arm-none-eabi-gcc on macos (gcc-arm-none-eabi-49 from homebrew) but a friend is experiencing the same using the same toolchain on windows.

User avatar
Giovanni
Site Admin
Posts: 10004
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 185 times
Been thanked: 168 times
Contact:

Re: USB on STM32F3DISCOVERY

Postby Giovanni » Mon Jul 17, 2017 3:39 pm

Hi,

There is a bug related to USB already fixed in trunk code (failed check in usbStart(), bug #863), you may try checking out from subversion and give it a try.

The fix will be included in 17.6.1 and 16.1.9.

Giovanni

zwhite
Posts: 4
Joined: Mon Jul 17, 2017 5:59 am

Re: USB on STM32F3DISCOVERY

Postby zwhite » Mon Jul 17, 2017 4:49 pm

Thanks for the pointer Giovanni, that does seem to fix a problem. Now the board works perfectly on my mac:

Code: Select all

zach-desktop:USB_CDC zwhite$ ioreg -p IOUSB | grep ChibiOS
  |   +-o ChibiOS/RT Virtual COM Port@fd330000  <class AppleUSBDevice, id 0x10001be30, registered, matched, active, busy 0 (11 ms), retain 16>


I can also use it on windows 7 and ubuntu 14.04.5 LTS through VirtualBox's USB device support. I'm able to unplug and plug in at will and everything works great.

Code: Select all

Jul 17 08:18:30 builder kernel: [1937713.265044] usb 1-1: new full-speed USB device number 3 using ohci-pci
Jul 17 08:18:31 builder kernel: [1937713.620333] usb 1-1: New USB device found, idVendor=0483, idProduct=5740
Jul 17 08:18:31 builder kernel: [1937713.620337] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jul 17 08:18:31 builder kernel: [1937713.620339] usb 1-1: Product: ChibiOS/RT Virtual COM Port
Jul 17 08:18:31 builder kernel: [1937713.620341] usb 1-1: Manufacturer: STMicroelectronics
Jul 17 08:18:31 builder kernel: [1937713.620342] usb 1-1: SerialNumber: 400


However, it still does not successfully negotiate USB on the raspberry pi, an original version B from 2011. Using the same USB cable plugged into the same USB port on the Pi I can get st-link to work fine, but moving the cable from the ST-LINK port to the USER port results in nothing. I don't even see any activity on the USB bus.

Code: Select all

pi@laser-monitor:~ $ sudo tcpdump -Xxni usbmon0 -w usb_dump_usbmon0.pcap
tcpdump: listening on usbmon0, link-type USB_LINUX_MMAPPED (USB with padded Linux header), capture size 262144 bytes

# Plug in USER port here, wait until "North" LED starts blinking, unplug

^C652 packets captured
658 packets received by filter
0 packets dropped by kernel
pi@laser-monitor:~ $ tcpdump -Xxr usb_dump_usbmon0.pcap | grep 'BULK' | grep -v '1:3:[12]'  # Filter out hub and ethernet traffic
reading from file usb_dump_usbmon0.pcap, link-type USB_LINUX_MMAPPED (USB with padded Linux header)


I do see activity when I do the same experiment on the stlink port:

Code: Select all

pi@laser-monitor:~ $ sudo tcpdump -Xxni usbmon0 -w stlink_dump_usbmon0.pcap
tcpdump: listening on usbmon0, link-type USB_LINUX_MMAPPED (USB with padded Linux header), capture size 262144 bytes
^C558 packets captured
564 packets received by filter
0 packets dropped by kernel
pi@laser-monitor:~ $ tcpdump -Xxr stlink_dump_usbmon0.pcap | grep 'BULK' | grep -v '1:3:[12]' | head  # Filter out hub and ethernet traffic
reading from file stlink_dump_usbmon0.pcap, link-type USB_LINUX_MMAPPED (USB with padded Linux header)
08:34:32.578197 BULK SUBMIT to 1:126:3
08:34:32.578399 BULK COMPLETE from 1:126:3
08:34:32.578524 BULK SUBMIT to 1:126:3
08:34:32.578779 BULK COMPLETE from 1:126:3
08:34:32.578821 BULK SUBMIT to 1:126:3
08:34:32.579015 BULK COMPLETE from 1:126:3
08:34:32.583867 BULK SUBMIT to 1:126:3
08:34:32.584168 BULK COMPLETE from 1:126:3
08:34:32.584216 BULK SUBMIT to 1:126:3
08:34:32.584395 BULK COMPLETE from 1:126:3


Any idea why it's not working on the pi?

User avatar
Giovanni
Site Admin
Posts: 10004
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 185 times
Been thanked: 168 times
Contact:

Re: USB on STM32F3DISCOVERY

Postby Giovanni » Mon Jul 17, 2017 5:43 pm

Hi,

No idea, however consider that the CDC implementation in the demo is not complete, it only handles a subset of all possible CDC messages, if an unhandled message is received the data endpoint is stalled.

You may try to place breakpoints in the usb_serial.c messages handler and see if something unsupported is received. If so, then you need to provide the message handler in your application code, the default handler is extensible without having to modify it.

Giovanni

rew
Posts: 218
Joined: Sat Jul 19, 2014 12:59 pm
Been thanked: 1 time

Re: USB on STM32F3DISCOVERY

Postby rew » Tue Jul 18, 2017 6:53 am

The thing is... Linux is Linux, if it runs on a pi or on a PC. I don't expect Linux to start sending different USB packages depending on which hardware it is running on. There may be a low-level driver that's different, but the layers on top remain the same.

avrhack
Posts: 114
Joined: Tue Dec 24, 2013 1:42 pm
Has thanked: 7 times
Been thanked: 1 time

Re: USB on STM32F3DISCOVERY

Postby avrhack » Tue Jul 18, 2017 7:30 am

Try cat /sys/kernel/debug/usb/usbmon/0u and it will show you all the USB packets so you can figure out exactly which transaction is causing the problem. Would suggest you post the final few lines of that output here.

If that file doesn't exist check if you have a debugfs mounted. If not use mount -t debugfs none_debugs /sys/kernel/debug

Then you will also need to use modprobe usbmon to enable USB debug output

User avatar
Giovanni
Site Admin
Posts: 10004
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 185 times
Been thanked: 168 times
Contact:

Re: USB on STM32F3DISCOVERY

Postby Giovanni » Tue Jul 18, 2017 7:49 am

Good to know :) my Linux-fu is not so strong.

Giovanni

avrhack
Posts: 114
Joined: Tue Dec 24, 2013 1:42 pm
Has thanked: 7 times
Been thanked: 1 time

Re: USB on STM32F3DISCOVERY

Postby avrhack » Tue Jul 18, 2017 7:54 am

Giovanni wrote:Good to know :) my Linux-fu is not so strong.

Giovanni


Yes I struggled many times in troubleshooting my USB code on Chibi because you can't put in breakpoints for obvious reasons and even trace output can change the timing of course. But on linux being able to see every submitted and completed/errored URB means you can literally get it down to the individual on-bus transaction. Even better, if you attach the device on a USB bus on its own and use one of the 1u-2u-3u etc devices, only the transactions for that device will be shown which gets rid of a lot of chatter.

Only downside is that the output is very hard to read; there is a binary API though for those who can be bothered to write a tool producing 'nicer' lines which I'm working on at the moment. If I ever finish it I'll pop a link to it here as it might help with Chibi USB debugging for others.


Return to “STM32 Support”

Who is online

Users browsing this forum: elagil and 1 guest