Strange behaviour with USB serial

[Ceco]

Hello.
I have a strange behavior with my system which is composed as follow:
STM32F427
Chibios 2.6.6
Serial driver on USART1 used for debug print.
USB Serial driver.

USB Serial driver is started but currently not in use. Anyway it enumerates correctly - I'm seeing it in Device Manager of Windows. But if I'm using intensively USART1 to print debug messages, from time to time the USB is disconnected and reconnected again. I can see this in device manager of Windows and I hear the sound. The debug messages are printed from main thread, which has normal priority. I'm just using chvprintf redirected to BaseSequentialStream of SD1.

Did I made something wrong with two serial drivers working together?

[Giovanni]

The two drivers should work perfectly together.

I suggest to enable the debug options and see if something is caught.

Giovanni

[Ceco]

I have enabled all debug options. There is no calls to chDbgPanic. What else I can check?

It' really strange because the USB disconnects and connects again rapidly during chvprintf (redirected to SD1) usage. With a oscilloscope I can see a drop in the data stream on D+/D- lines for about 100ms. In the same time it stays connected if i put a hardware breakpoints any where in the code.

[Giovanni]

The board could be resetting for some reason and that would trigger a new enumeration, alternatively there could be an electrical problem on the USB. You should also check the USB host port, ports expanders, cables etc.

Giovanni

[Ceco]

Hm, if I have a reset on the CPU ,I will see it in the device behavior. Everything on the board works like expected until i'm starting to print on USART1. The printf itself also works fine, just disconnects the USB for a short time. On each printf, I have a "bing" sound. It's crazy

[Giovanni]

You could have a stack overflow, the detection mechanism only works on overflows in the moment of context switch.

Giovanni

[Ceco]

What I know for the moment is, that when I start to printf, I have a call to usb_lld_serve_interrupt() and _usb_reset().

[russian]

I am using USB serial and UART drivers together, they work fine.

I have to mention that while I've experienced all kinds of stack overflow issues and other crashes, I've never seen usb re-enumerations. Do you think the cpu reboots? Do you want to add some counter keeping track of time to see if it would be reset?

Having multiple drivers might cause IRQ nesting - the more devices with different IRQ priorities you are using, the higher nesting level you might end up. As an investigation technique, try setting all priorities to the same value and see if this would help?

[Ceco]

I'm pretty sure that device do not goes through reset procedure once after power on. I'm using an hardware debugger so I'm seeing that program flows like it it's planed. But it's good to know that this combination is used by other developers with success, so probably I have some problem in my code, maybe it's a stack overflow or something like this. Normally I'm using a lot of interrupts in my system, so nesting situations are clearly possible. I will report as soon as I have answer

Have a nice and healthy New Year!

Edit:
I have some doubt that the problem can comes some how from the pinout. For USB I'm using only D+ and D- lines - PA11/PA12. For USART1 - TX/RX which are PA9/PA10. But these pins are also related to OTG - VBUS and ID. I have no plans to use OTG functionality, only clear USB device behavior. So PA9 and PA10 are routed to USART1 alternative function. But if the USB hardware inside the STM32 still monitors these pins (especially VBUS)... I need to check this with real hardware next days...

Edit(2):
Yes, seems the problem is exactly in pinout. If I route the PA9 to USART_TX - I have USB disconnection on each UART frame transmission. If I configure the pin like GPIO output with high level, the printfs no more disturb USB, even if USART1 module is working, only the pin is not routed to it.
So this means that somehow USB hardware continues to look VBUS pin. I hope this is some configuration bit and can be changed. Because my board is ready, If I need a new PCB this will be very bad from budgetary point of view.

Anyway the problem it's not related to the chibios.

[Ceco]

Yes, there is a "hook" for this problem in Chibios
#define BOARD_OTG_NOVBUSSENS

Now all works fine... or it seems to work fine. Thanks for the help!