USB Lib: Enable 4-Byte alignment ALWAYS (not only for DMA!!!)

[flyer31]

Posted on June 21, 2012 at 14:26

The USB EP buffers defined in usbd_cc_core.cpp definitely NEED to be 4-byte aligned. Otherwise you end up in Memory-Alignment fault / Hard fault (if it is enabled by setting SCB->CCR |= 0x18 - this you definitely should always do).

To get this, please take care that the macros __ALIGN_BEGIN and __ALIGN_END are ALWAYS defined correctly. To get this done, please change the code segment in usb_conf.h to the following:

//#ifdef USB_OTG_HS_INTERNAL_DMA_ENABLED

  #if defined   (__GNUC__)        /* GNU Compiler */

    #define __ALIGN_END    __attribute__ ((aligned (4)))

    #define __ALIGN_BEGIN         

  #else                           

    #define __ALIGN_END

    #if defined   (__CC_ARM)      /* ARM Compiler */

      #define __ALIGN_BEGIN    __align(4)  

    #elif defined (__ICCARM__)    /* IAR Compiler */

      #define __ALIGN_BEGIN

    #elif defined  (__TASKING__)  /* TASKING Compiler */

      #define __ALIGN_BEGIN    __align(4)

    #endif /* __CC_ARM */  

  #endif /* __GNUC__ */

//#else

//  #define __ALIGN_BEGIN

//  #define __ALIGN_END   

//#endif /* USB_OTG_HS_INTERNAL_DMA_ENABLED */

(Comment out the first line and the last 4 lines, so that __ALIGN_BEGIN and __ALIGN_END always do their job). Otherwise, if you define some char field with ''char acEndpointBuf[64]'', this will possibly NOT be aligned, which then leads to running into HardFault trap. (I had a USB software running nicely, and when changing the module order in the Keil project list, suddently I got such HardFault trap - looking into it, I recognized that by changing the module order, the linkage was changed, and my Endpoint Buffers lost their 4-byte alignment ... - this took me some hours).

[Tesla DeLorean]

Posted on June 21, 2012 at 17:39

this took me some hours

Thanks for the heads-up, your report will no doubt save many more frustrating hours by others. Can't +1 an initial post, but would have, stupid Microsoft forum.

[flyer31]

Posted on June 22, 2012 at 10:13

Further there is one very strange command in the USB pin configuration file USB_BSP.C (function USB_OTG_BSP_Init):

  /* enable the PWR clock */

  RCC_APB1PeriphResetCmd(RCC_APB1Periph_PWR, ENABLE);    If they really want to enalbe the PWR clock, then it would be necessary to use the command RCC_APB1PeriphClockCmd instead of ...ResetCmd. The ResetCmd will reset the Power interface (which is more or less useless, as typically this function USB_OTG_BSP_Init is invoked quite directly after reset). But in any case I do NOT really understand, why it should be necessary to switch on the ''power interface clock'' - in the reference manual this clock seems to be necessary only, if I want to access to RTC RAM or Backup RAM - but I think USB does not need any of them? (So I commented out this line now, and USB still working :) ...) PS: I am just checking unused functions in my software with the Keil linker setting --feedback=filename ... . Therefore I saw that this Reset command is used in USB_BSP, which I thought is really strange (no Reset command used anywhere else in my software). PPS: Further it should be noted here, that in the USB lib currently there is quite a mixup between the defines ''USB_OTG_FS/HS_CORE'' and ''USE_OTG_FS/HS''. The USE_... define should specify the speed of the module. The ..._CORE define should specify the used USB peripherial. As the HS core can work with FS as well as HS mode, and as these defines look very similar, it gets a bit tricky now. My USB code worked nicely with FS peripheral in FS mode, and HS peripheral in HS mode, but I needed again several hours to engage the HS peripheral in FS mode (using the on-board PHY) - for this it is necessary to look very closely at all points where these 4 defines are used, and at some points they are mixed up - this needs to be corrected (If you know any of the ST people, just please ask them to check, that the HS peripheral also works with the on-board FS PHY, if they define USB_OTG_HS_CORE and USE_USB_OTG_FS).