stm32f4 doesn't work when compile with gcc 8.3.1 with -Os

[hathach]

Describe the bug

• example cdc_msc_hid doesn't work when compiled with gcc 8.3.1 with -Os. It works with gcc v7 though

Set up (please complete the following information):

• OS: Ubuntu 18.04
• Board: stm32f407disco
• Firmware Code: examples/device/cdc_msc_hid

To Reproduce
compile with gcc 8.3.1

Expected behavior
usb device is not recognized

[cr1901]

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?

[hathach]

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 :)

[hathach]

close by PR #114