USB CDC on STM32F746 with ChibiOS 16.1

[Giovanni]

Hi,

If you could make a list of unhandled messages and how to handle them (or stub them) I could add to the default handler.

Giovanni

[Korken]

I am more than willing to help, though I am not anywhere near proficient with USB.
But I got Wireshark to log the USB.

What is it that you need and I will try and provide it.
I have a Wireshark log of the procedure when I open a port, but I have no idea what the details mean.
But I can see the standard transfers where device descriptors are sent and all that, plus there seem to be a lot of malformed packets.
I have added the log so you can have a look.

[seawalker]

Hi,(Bonjour !)

So, for me, my first issue was VBus sense flag (thanks Giovanni!)
http://www.chibios.com/forum/viewtopic.php?f=2&t=623&start=10

@korken
Thanks to remember me Whireshark usbmon capture.!!

With Cutecom, it's ok to open /dev/ttyACM0 and it starts to receive endless and for a while....
I am using demos sample cdc with blinking thread and sending word "test" each sec in the main loop.
Like this, seems ok, but looking in capture file, it's not so evident!. I'm not too sufficiently "aware" of Usb otg...
see attached file for a connection of the cable on linux(fc23) wich looks great displayed on a terminal.
( the descriptor is not uptaded and the cpu is a F405)

Could be a sysnchronization problem in Wireshark capture ?

Now, i can go forward in my project, but i will continue to follow and inform you if something new

Thanks to share

Gilles

[Giovanni]

I am unable to replicate the problem and I don't see anything obvious in the code.

Could you post a stack trace when the assertion is triggered?

Also, could you try an STM32 with the normal USB instead of OTG? that would allow me to rule out a problem in the low level driver if the same problem occurs, F1, F3, F0, L0, L1 would work.

Giovanni

[Giovanni]

@seawalker

I also tested using cutecom last time, probably this is why I didn't see the issue.

@korken

What is the exact procedure that triggers the problem?

Giovanni

[Korken]

The procedure that triggers the problem is as follows:
1. Having an MCU running the USB code (only in my case, nothing else).
2. Connecting the USB as normal.
3. Waiting for the ttyACMx to become visible
4. Running "minicom -D /dev/ttyACMx"
5. The program take some time to open the port (like a timeout has happened)
6. The port opens and the board halts with the described error.

A backtrace as requested:

Code: Select all

Program received signal SIGINT, Interrupt.
0x0020076e in chSysHalt (reason=reason@entry=0x8008130 <__func__.9732> "obqReleaseEmptyBufferI")
    at ./ChibiOS/os/rt/src/chsys.c:203                                                          
(gdb) bt
#0  0x0020076e in chSysHalt (reason=reason@entry=0x8008130 <__func__.9732> "obqReleaseEmptyBufferI")
    at ./ChibiOS/os/rt/src/chsys.c:203                                                              
#1  0x002023ae in obqReleaseEmptyBufferI (obqp=0x8008130 <__func__.9732>,
    obqp@entry=0x2000181c <SDU1+64>) at ./ChibiOS/os/hal/src/hal_buffers.c:522
#2  0x00203288 in sduDataTransmitted (usbp=0x20001310 <USBD1>, ep=<optimized out>)
    at ./ChibiOS/os/hal/src/hal_serial_usb.c:426                                  
#3  0x00204dde in otg_epin_handler (usbp=usbp@entry=0x20001310 <USBD1>, ep=ep@entry=1 '\001')
    at ./ChibiOS/os/hal/ports/STM32/LLD/OTGv1/hal_usb_lld.c:384                              
#4  0x002050e4 in usb_lld_serve_interrupt (usbp=0x20001310 <USBD1>)
    at ./ChibiOS/os/hal/ports/STM32/LLD/OTGv1/hal_usb_lld.c:601    
#5  Vector14C () at ./ChibiOS/os/hal/ports/STM32/LLD/OTGv1/hal_usb_lld.c:645
#6  0xffffffec in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) 

For more testing, I do sadly only have boards with F4 and F7s here.

I have tested CuteCom and RealTerm, both give the same erroneous behaviour.

[rew]

cdc_acm 1-2:1.0: failed to set dtr/rts

It seems that something is not implemented that has to do with the DTR/RTS signals that I am missing,

No. This happens when the STM suddenly disappears. Then the Linux driver tries to set DTR/RTS on the just-now-nonexistant usb-serial port.

you say it happens when the chip "panics", but I've only seen it when the chip resets. The panic in my case leaves enough of the usb-hardware running to have Linux think the chip is still there, but it seems that in your case the panic already resets enough USB hardware to worry Linux.

Korken, for testing, install the package "ckermit" and try kermit -l /dev/ttyACM0 . That's what works for me. (F0, F1 (long time ago), F3, F4, I don't have an F7 yet).

[Korken]

Okey, I have found a workaround for this problem which might give insight.
What I do when I test it is that I send some strings with chprintf in the main loop, and it only checks if there is an active USB connection to not send when it is not active.
* If I do not send any data at all, there is no halt.
* If I do not send data until after I have opened the port (wait with sending until a character has been received), there is no halt.

Does this help in any way?

[Giovanni]

It helps because the driver is not supposed to halt the system under any externally triggered error condition.

I am reinstalling Mint on my laptop, I will give it a try during vacations.

Giovanni

[Korken]

Great! Mint is quite easy to use, personally I run Manjaro

When I did this I got a feeling of an internal buffer/counter overflowing, is this a possibility?
I saw with Wireshark that no packets are sent over the USB until after the port is opened, but the "print" function still "sends" (I believe it queues it?) the data to some internal buffer.