MX_USB_DEVICE_Init() causes program to stall, possibly due to low-quality USB power supply

[Sebastiaan]

Hello,

We observe issues with a set of stm32F407ZETx.

The application stalls / hangs somewhere while calling MX_USB_DEVICE_Init(). We are using the USB in CDC class. The board is powered via a USB cable, and the issue is not observed when using a good-quality USB power block, but it is observed if we e.g. put a dongle in between (https://us.transcend-info.com/product/card-reader-accessory/hub2). The production site (in a different country) is also observing these issues, I'll ask if they use a hub as well.

The application seems to hang, but I could not pinpoint where exactly, since the program counter register suddenly becomes 0x0!!! That seems to happen on a random place during MX_USB_DEVICE_Init(). Sometimes, the application recovers automatically (on the production site, they say that the startup time usually takes 2 minutes instead of 3 seconds), but on our reproduction setup, the application never recovers automatically.

Surprisingly, the application DOES recover if we touch the groundplane with e.g. a pin from a multimeter. We have had strange observations when e.g. plugging in the programmer, but eventually we could pin it down to 'touching' the groundplane.

This is all very puzzling, but I still assume that there is a common root cause for the observations. So as a summary, I'd like to know:

• How can the program counter suddenly become 0x0?
• How can the program automatically resume after touching the ground plane?
• How can this be caused by the function MX_USB_DEVICE_Init()?
  • We did not connect USB_OTG_FS_ID and USB_OTG_FS_VBUS pin on the MCU.
  • How can it be caused by a low-quality USB supply? Our first analysis shows that the convertor to 3.3V seems quite stable, and the USB_DEVICE_Init() is far from the first function to be called (so the voltage should be quite stable).
  • If we disable the USB initialization, we clearly don't have the logging functionality but apart from that the application works all fine.
• I've seen other threads about program counters becoming 0x0 but that was caused by missing entries in the interrupt table, as far as I could see.
• I'm using cubeide 1.3.0 and cubemx 5.6.1. I have not yet tried to upstep to newer versions for this project.

[Amel NASRI]

Hi @Sebastiaan​ ,

Could you please first make sure to be aligned with latest tools versions & latest USB libraries?

Then let us know if problem is still there or not.

-Amel

[Sebastiaan]

Hello Amel,

I have tried with the following combination:

• stm32 cube mx 6.8.0
• FW package for stm32f4: 1.27.1
• stm32 cube ide 1.12.0

The behavior is exactly the same, the issue is still there.

[MWB_CHa]

Hi @Sebastiaan​ ,

Is it possible please to do the same test using the standard example provided in STM32F4 CubeFW ?(https://github.com/STMicroelectronics/STM32CubeF4/tree/master/Projects/STM324xG_EVAL/Applications/USB_Device/CDC_Standalone )

Of course it is not the same board, but the example doesn't use significant resources from the board except LEDs and some IOs that you can remap or completely ignore/remove.

The objective is to first isolate the root cause category (software/hardware).

My first intuition would be that when USB is activated, it drains more current from the supply and uncovers the existing issue of the unstable power which leads to supply failure which would explain the 0x00 on program counter. But this is just a first guess. Need some additional tests to confirm the direction of debugging.

We'd appreciate if you can do the test with the standard example.

[Sebastiaan]

Hi all,

I was about to start testing the standard example. Unfortunately, quite some desks have been shuffled around at the office and I'm no longer able to reproduce the original issue. It's possible that we daisy-chained too many power extenders in the past, and that this also had an influence on the occurrence rate.

For the sake of giving some answers:

• we work with a peripheral power supply, which means that some of the peripheral components are powered on our control. I've tried to put sufficient sleep time (in the order of second) for these components to stabilize.
• I certainly suspect power instability as well. It's just that the program counter of 0x0 seems very odd to me, and another point is that the CPU seems to resume after touching /interaction with the ground plane. So that's mainly why I raised this ticket, with the hope to give more info towards the hardware engineer.

As long as I can't reproduce, there's not much I can do. So if you prefer, the ticket can be closed for now.

[MWB_CHa]

Hi @Sebastiaan​ 

Thanks a lot for posting the update, it's very helpful and for other community users.

Indeed, without a reproduction scheme not much can be done. But at least this provides us an additional information: the issue is related to a specific configuration of the power on specific devices.

It consolidates the idea that USB activation, draining more current, exposes the power supply instability.

Anyway, please feel free to come back to this topic anytime you have more info/details.