USB CDC example crashes

[Rüdiger]

Hi,

I'm trying to run the (unmodified) example in testhal/STM32/STM32F0xx/USB_CDC on my STM32F072B-Discovery.
The code is from svn r10430, compiler is arm-none-eabi-gcc 7.1.0.

I'm able to flash the controller and run the code and I can also connect to the board and use the terminal, but after maybe
10-20 seconds, the board stops responding. According to GDB, it is in _unhandled_exception(void) and I get no meaningful backtrace.

Observations so far:
-The crash only happens when the USB cable is connected, otherwise it runs fine (but then it's kind of pointless...)
-I see no USB packets in wireshark related to the crash, it even crashes when no terminal is connected and then I only see the initial enumeration.
-When connecting a terminal, I see weird packets from the device to the host which wireshark identifes as Ethernet II. I'm not sure if this is normal for CDC, but it looks suspicious.

[Rüdiger]

I did some more tests to narrow the problem down.
I tested GCC 7.1.0 from the Archlinux repositories, GCC 6.3.1 from here and GCC 5.4.1 from here.

The binaries produced by GCC 7 and GCC 6 crash after a few seconds, the binary produced by GCC 5 runs without issues for hours.
The problem also disappears for the other GCC versions when I disable optimizations (-O0). The traffic in wireshark looks the same in all cases,
including (allegedly?) malformed packets and weird ethernet II packets.
So it seems that some of the optimizations in newer versions of GCC break something?

I also tried the USB_CDC example for the stm32f4-discovery, and that runs fine indepentend of the GCC version and the optimizations.
Also, I don't see any of the weird malformed packets and ethernet II packets in wireshark, which I had on the stm32f072-discovery.

[Giovanni]

Hi,

This is not the first time that GCC 6+ breaks something, I have not been yet able to understand the problem.

Note that F0 and F4 have different USB peripherals and drivers, F0 uses USBv1 F4 uses OTGv1. Probably it is something in the USBv1 driver that triggers the problem.

Right now I am not at home and have no way to do tests, if you have more info please post here.

Could you try to run enabling checks, assertions and state checker? if something is caught then we could have an hint about the problem.

Giovanni

[geoffrey.brown]

I've had some luck identifying crash sites by adding the following to my code . Not sure it'll help in your case, but it at least gives GDB a fighting chance.

volatile uint32_t vecactive;
void _unhandled_exception(void) {
vecactive = (*((uint32_t *) 0xE000ED04U)) & 0xff;
while (true);
}

// this sets up the stack so gdb can unwind it

void HardFault_Handler(void) {
__asm( ".syntax unified\n"
".thumb\n"
"tst lr, #4\n"
"ite eq\n"
"mrseq r0, msp\n"
"mrsne r0, psp\n"
"mov sp, r0\n"
"bkpt #1\n");
while (1);
}