7

概括

我正在使用最新版本的 Sourcery CodeBench Lite 工具链（GCC arm-none-eabi 4.7.2）将 ST 的 USB OTG 库移植到定制的 STM32F4 板上。

当我用 -O0 编译代码时，程序运行良好。当我使用 -O1 或 -O2 编译时，它会失败。当我说失败时，它就停止了。没有硬故障，什么都没有（嗯，很明显它正在做一些事情，但我没有一个模拟器可以用来调试和发现，对不起。我的硬故障处理程序没有被调用）。

细节

我正在尝试调用以下函数...

void USBD_Init(USB_OTG_CORE_HANDLE *pdev,
           USB_OTG_CORE_ID_TypeDef coreID, 
           USBD_DEVICE *pDevice,                  
           USBD_Class_cb_TypeDef *class_cb, 
           USBD_Usr_cb_TypeDef *usr_cb);

...但它似乎没有进入函数体。（这是“堆栈粉碎”的症状吗？）

传递给此函数的结构具有以下定义：

typedef struct USB_OTG_handle
{
  USB_OTG_CORE_CFGS    cfg;
  USB_OTG_CORE_REGS    regs;
  DCD_DEV     dev;
}
USB_OTG_CORE_HANDLE , *PUSB_OTG_CORE_HANDLE;

typedef enum
{
  USB_OTG_HS_CORE_ID = 0,
  USB_OTG_FS_CORE_ID = 1
}USB_OTG_CORE_ID_TypeDef;

typedef struct _Device_TypeDef
{
  uint8_t  *(*GetDeviceDescriptor)( uint8_t speed , uint16_t *length);  
  uint8_t  *(*GetLangIDStrDescriptor)( uint8_t speed , uint16_t *length); 
  uint8_t  *(*GetManufacturerStrDescriptor)( uint8_t speed , uint16_t *length);  
  uint8_t  *(*GetProductStrDescriptor)( uint8_t speed , uint16_t *length);  
  uint8_t  *(*GetSerialStrDescriptor)( uint8_t speed , uint16_t *length);  
  uint8_t  *(*GetConfigurationStrDescriptor)( uint8_t speed , uint16_t *length);  
  uint8_t  *(*GetInterfaceStrDescriptor)( uint8_t speed , uint16_t *length);   
} USBD_DEVICE, *pUSBD_DEVICE;

typedef struct _Device_cb
{
  uint8_t  (*Init)         (void *pdev , uint8_t cfgidx);
  uint8_t  (*DeInit)       (void *pdev , uint8_t cfgidx);
 /* Control Endpoints*/
  uint8_t  (*Setup)        (void *pdev , USB_SETUP_REQ  *req);  
  uint8_t  (*EP0_TxSent)   (void *pdev );    
  uint8_t  (*EP0_RxReady)  (void *pdev );  
  /* Class Specific Endpoints*/
  uint8_t  (*DataIn)       (void *pdev , uint8_t epnum);   
  uint8_t  (*DataOut)      (void *pdev , uint8_t epnum); 
  uint8_t  (*SOF)          (void *pdev); 
  uint8_t  (*IsoINIncomplete)  (void *pdev); 
  uint8_t  (*IsoOUTIncomplete)  (void *pdev);   
  uint8_t  *(*GetConfigDescriptor)( uint8_t speed , uint16_t *length);  
  uint8_t  *(*GetUsrStrDescriptor)( uint8_t speed ,uint8_t index,  uint16_t *length);   

} USBD_Class_cb_TypeDef;

typedef struct _USBD_USR_PROP
{
  void (*Init)(void);   
  void (*DeviceReset)(uint8_t speed); 
  void (*DeviceConfigured)(void);
  void (*DeviceSuspended)(void);
  void (*DeviceResumed)(void);  

  void (*DeviceConnected)(void);  
  void (*DeviceDisconnected)(void);    

}
USBD_Usr_cb_TypeDef;

我试图包含与此问题相关的所有源代码。如果您想查看完整的源代码，可以在这里下载：http: //www.st.com/st-web-ui/static/active/en/st_prod_software_internet/resource/technical/software/firmware/stm32_f105-07_f2_f4_usb -host-device_lib.zip

尝试的解决方案

我尝试使用#pragma GCC optimize ("O0"),__attribute__((optimize("O0")))并将某些定义声明为volatile，但没有任何效果。我宁愿只修改代码以使其与优化器很好地配合使用。

问题

如何修改此代码以使其与 GCC 的优化器配合使用？

4

1 回答 1

2

您显示的代码似乎没有任何问题，所以这个答案会更笼统。

“接近硬件”代码在未经优化的情况下正常工作并在更高优化级别下失败的典型错误是什么？

想想-O0和之间的区别-O1/-O2：优化策略是——除其他外——循环展开（似乎并不危险）、尽可能长时间地将值保存在寄存器中、消除死代码和指令重新排序。

如果没有正确声明可以随时更改的硬件寄存器，改进的寄存器使用通常会导致更高优化级别的问题volatile（请参阅上面的 PokyBrain 评论）。优化后的代码将尝试尽可能长时间地将值保存在寄存器中，从而导致您的程序无法注意到硬件方面的变化。确保volatile正确声明硬件寄存器

如果您需要读取硬件寄存器以对编译器不知道的硬件产生任何影响并且不对您刚刚读取的值做任何事情，那么死代码消除可能会导致问题。如果您没有正确声明用于读取访问的变量，这些硬件访问可能会被优化掉void（尽管编译器应该发出警告）。确保将虚拟读取投射到(void)

指令重新排序：如果您需要以特定顺序访问不同的硬件寄存器以产生所需的结果，并且如果您通过与其他方式无关的指针来执行此操作，编译器可以自由地重新排序结果指令，因为它认为合适（即使硬件寄存器已正确声明volatile）。您需要在代码中添加内存屏障以强制执行所需的访问顺序 ( __asm__ __volatile__(::: "memory");)。确保在需要的地方添加内存屏障。

尽管不太可能，但您仍然可能发现了编译器错误。优化不是一件容易的事，尤其是当它接近硬件时。可能值得一看 gcc 错误数据库。

如果这一切都没有帮助，您有时无法避免深入研究生成的汇编代码，以确保它在做它应该做的事情。

于 2014-04-06T07:01:30.967 回答