STM32F4xx USB bug, when compiled by GCC using -O3 option.

[Evgeny Sobolev]

Setup:

Project, generated by CubeMX and compiled by arm-none-eabi-gcc-9.2.0 toolchain.

CubeMX firmware package version: STM32Cube FW_L4 V1.14.0

CPU: STM32L432KCY (and others)

Toolchain: arm-none-eabi-gcc-9.2.0 (and others)

Compiler options: -mcpu=cortex-m4 -mthumb -mfloat-abi=softfp -mfpu=fpv4-sp-d16 -O3 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -fno-inline-functions

Problem:

Usb not working properly.

Solution:

FunctionUSB_WritePMA, not working properly when project compiled using -O3 optimization option. Let's look at the file stm32l4xx_ll_usb.c. Pls. look at the function

/**
  * @brief Copy a buffer from user memory area to packet memory area (PMA)
  * @param   USBx USB peripheral instance register address.
  * @param   pbUsrBuf pointer to user memory area.
  * @param   wPMABufAddr address into PMA.
  * @param   wNBytes: no. of bytes to be copied.
  * @retval None
  */
void USB_WritePMA(USB_TypeDef *USBx, uint8_t *pbUsrBuf, uint16_t wPMABufAddr, uint16_t wNBytes)
{
  uint32_t n = ((uint32_t)wNBytes + 1U) >> 1;
  uint32_t BaseAddr = (uint32_t)USBx;
  uint32_t i, temp1, temp2;
  uint16_t *pdwVal; // Fix:  make it volatile // volatile uint16_t *pdwVal;
  uint8_t *pBuf = pbUsrBuf;
 
  pdwVal = (uint16_t *)(BaseAddr + 0x400U + ((uint32_t)wPMABufAddr * PMA_ACCESS));
 
  for (i = n; i != 0U; i--)
  {
    temp1 = (uint16_t) * pBuf;
    pBuf++;
    temp2 = temp1 | ((uint16_t)((uint16_t) * pBuf << 8));
    *pdwVal = (uint16_t)temp2;
    pdwVal++;
 
#if PMA_ACCESS > 1U
    pdwVal++;
#endif
 
    pBuf++;
  }
}

volatile uint16_t *pdwVal;

After fix:

[Imen.D · Accepted solution]

Hello @Evgeny Sobolev (Community Member)​ ,

This issue will be fixed in the next release of STM32CubeL4 V1.15.

So, please keep an eye out for the next update!

Thank you for highlighting this issue.

Best Regards,

Imen

[Evgeny Sobolev]

Please don't forget to fix it on another controller families.

Thanks.

[Dave Nadler]

@Evgeny Sobolev​ - Thanks for the fix.

Can you explain what the compiler did that using volatile solves?

While that code obviously leaves plenty of room for improvement, I don't see any obvious aliasing or other coding errors?

Thanks!

Best Regards, Dave