stm32f4 doesn't work when compile with gcc 8.3.1 with -Os about tinyusb HOT 3 CLOSED

Commit 8f8ca77 will fixes this for Nucleo, but the fix applies to all STM32 targets.

AFAIK, there isn't a nice typedef in the STM32 headers for accessing the TX/RX FIFOs, so I used a uint32_t *. Because I forgot the volatile qualifier for the FIFO pointers, gcc 8.3.1 decided during optimizations to turn the setup packet-handling code from this:

_setup_packet[4 - 2*setup_left] = (* rx_fifo);
_setup_packet[5 - 2*setup_left] = (* rx_fifo);

to this:

_setup_packet[4 - 2*setup_left] = (* rx_fifo);
_setup_packet[5 - 2*setup_left] = _setup_packet[4 - 2*setup_left];

Because a read from RX FIFO was optimized away, this meant that the RX FIFO wasn't in a proper state (empty or aligned to a status word) when OTG_FS_IRQHandler finished. Then the RXLEVEL interrupt triggered again, and the read_rx_fifo function read the RX FIFO entry that should've been placed in _setup_packet[5 - 2*setup_left].

Since the data that goes into _setup_packet[5 - 2*setup_left] is not a status word, read_rx_fifo sees garbage and triggers a TU_BREAKPOINT. Marking the FIFO pointers as volatile forces all RX/TX FIFO reads and writes to actually occur, fixing the bug.

This was fun to debug :D!... I think?

from tinyusb.

Superb !! thanks for the fix. Will close this issue once that PR is merged. volatile keyword indeed is source of many optimization issue, I made lots of mistake with it in the past as well :)

from tinyusb.

close by PR #114

from tinyusb.