STM32H7 USB driver fails highest optimization (-O3)

IMHO this should not be a problem...

Example:
 
uint32_t USB_ReadInterrupts(USB_OTG_GlobalTypeDef *USBx)
{
 uint32_t tmpreg;
 tmpreg = USBx->GINTSTS;
 tmpreg &= USBx->GINTMSK;
 return tmpreg;
}

The tmpreg variable should not be volatile here and in similar context.

static HAL_StatusTypeDef USB_CoreReset(USB_OTG_GlobalTypeDef *USBx)
{
 uint32_t count = 0U;
 /* Wait for AHB master IDLE state. */
 do
 {
 if (++count > 200000U)
 {
 return HAL_TIMEOUT;
 }
 }

In this case, yes. Even better, use a decent microsecond delay instead of this /*expletive*/ (a timer...)

-- pa

If all these volatile are really needed? Maybe not. But for sure there is an issue with this code:

Try to run USB (BTW: on any MCU) compiled with -O3 - it will fail.

After adding this to the code - it works

From the program correctness standpoint, the only accesses that have to be volatile are those which access the peripheral registers. Comparing the "corrected" functions' asm/disasm with with or without volatile (and in various -O settings) should reveal whether those accesses have been incorrectly optimized out or not. I doubt that they were, in any setting.

OTOH, unnecessary volatile accesses introduce delays (similarly as lower optimization settings), which may be necessary to cope with timing problems in the Synopsys IP.

Volatile also ensures the peripheral registers are accessed in the correct order, but again for that it's enough that the peripheral registers themselves are tagged so, not the temporary variables. Given we are talking here about CM7 which is superscalar, peripheral registers have to be also placed in Device region by MPU, so that's maybe one more thing to check.

Loopdelay is the school example for using volatile, although as school examples often do, for the wrong reason. But the real culprit here is the Synopsys IP not signaling correctly end of reset thus requiring any delay. That delay of course should be written properly.

JW

If you use STM32H750, then to my experience better add 10msec delay loop after clock start, before you start the USB ... .

Though STM32H743 should NOT need this to my experience.

(But I anyway hate O3 optimization level, as it usually gives only very small gains, but the assembly gets that much optimized, that debugging gets difficult ... at least concerning Keil ARMCC to my experience).