在HAL_PCD_MspInit()中执行__HAL_RCC_USB_CLK_ENABLE()宏时，是什么初始化STM32 USB BTABLE的内容? [英] What initialises the contents of the STM32's USB BTABLE when the __HAL_RCC_USB_CLK_ENABLE() macro is executed in HAL_PCD_MspInit()?

问题描述

我已使用STM32CubeMX/IDE为STM32F3DISCOVERY板生成USB HID项目.

USB BTABLE寄存器为零，表明BTABLE位于数据包存储区的起始位置.

(我在程序启动时将整个PMA归零，以避免过时的值.)

在执行__HAL_RCC_USB_CLK_ENABLE宏(在usbd_conf.c的HAL_PCD_MspInit()中)之前，BTABLE的值(在PMA中从索引0开始)为:

执行该宏后，值是:

宏扩展为:

do { \
    volatile uint32_t tmpreg; \
    ((((RCC_TypeDef *) ((0x40000000UL + 0x00020000UL) + 0x00001000UL))->APB1ENR) |= ((0x1UL << (23U))));\
    /* Delay after an RCC peripheral clock enabling */ \
    tmpreg = ((((RCC_TypeDef *) ((0x40000000UL + 0x00020000UL) + 0x00001000UL))->APB1ENR) & ((0x1UL << (23U))));\
    (void)tmpreg; \
} while(0U)

此宏如何导致BTABLE初始化?

(我需要pma[12]成为0x100而不是0x0，因为我想将端点3用于复合设备中的HID接口.我正在使用此简单的HID设备来测试不同端点的使用.将USBD_LL_Init()和#define HID_EPIN_ADDR中的0x81更改为0x83不足以更改pma[12]的值.pma[12]处使用了不正确的TX指针，并且在Wireshark中观察到损坏的数据.)

---

更新:

如果我添加代码以手动将pma[12]设置为0x100:

HAL_StatusTypeDef  HAL_PCDEx_PMAConfig(PCD_HandleTypeDef *hpcd,
                                       uint16_t ep_addr,
                                       uint16_t ep_kind,
                                       uint32_t pmaadress)
  ...
  /* Here we check if the endpoint is single or double Buffer*/
  if (ep_kind == PCD_SNG_BUF)
  {
    /* Single Buffer */
    ep->doublebuffer = 0U;
    /* Configure the PMA */
    ep->pmaadress = (uint16_t)pmaadress;

    // correct PMA BTABLE
    uint32_t *btable = (uint32_t *) USB_PMAADDR; // Test this.
    if (ep->is_in) {
        btable[ep->num * 4] = pmaadress;
    }
  }

pam[12]处的值确实被设置，但后来被覆盖:

解决方案

__ HAL_RCC_USB_CLK_ENABLE()启用USB模块的时钟.在启用之前，所有外围设备位置均读取为零.启用时钟后，实际的PMA内容将变为可见，无论是在复位之前写入的内容还是在通电后留下的随机垃圾.因此，执行__HAL_RCC_USB_CLK_ENABLE()与您的问题无关.

我不知道端点3的TX缓冲区地址在哪里被覆盖，但是我猜想它是多维数据集在决定在端点上发送数据时设置的.我不熟悉Cube，它具有发送USB数据包的API吗?

此外，再次检查您的pma数组是否具有正确的定义.在F1和我可能的F3上，每个32位位置都有一个2字节的值.

UPD:对不起，我首先看到了这个问题，但是您真正的问题是为什么TX地址被覆盖或设置不正确.

I have used STM32CubeMX/IDE to generate a USB HID project for the STM32F3DISCOVERY board.

The USB BTABLE register is zero, indicating that the BTABLE is at the start of the Packet Memory Area.

(I zero the whole PMA at program start, to avoid stale values.)

Just before the execution of the __HAL_RCC_USB_CLK_ENABLE macro (in HAL_PCD_MspInit() in usbd_conf.c) the values of the BTABLE (at index zero onwards, in the PMA are:

After that macro is executed, the values are:

The macro expands to:

do { \
    volatile uint32_t tmpreg; \
    ((((RCC_TypeDef *) ((0x40000000UL + 0x00020000UL) + 0x00001000UL))->APB1ENR) |= ((0x1UL << (23U))));\
    /* Delay after an RCC peripheral clock enabling */ \
    tmpreg = ((((RCC_TypeDef *) ((0x40000000UL + 0x00020000UL) + 0x00001000UL))->APB1ENR) & ((0x1UL << (23U))));\
    (void)tmpreg; \
} while(0U)

How does this macro cause the BTABLE to be initialised?

(I need pma[12] to be 0x100 instead of 0x0 as I want to use endpoint 3 for the HID interface in a composite device. I am using this simple HID device to test the use of a different endpoint. Changing 0x81 to 0x83 in USBD_LL_Init() and #define HID_EPIN_ADDR are not sufficient to change the value of pma[12]. The incorrect TX pointer at pma[12] is used and corrupt data is observed in wireshark.)

---

Update:

If I add code to manually set pma[12] to 0x100:

HAL_StatusTypeDef  HAL_PCDEx_PMAConfig(PCD_HandleTypeDef *hpcd,
                                       uint16_t ep_addr,
                                       uint16_t ep_kind,
                                       uint32_t pmaadress)
  ...
  /* Here we check if the endpoint is single or double Buffer*/
  if (ep_kind == PCD_SNG_BUF)
  {
    /* Single Buffer */
    ep->doublebuffer = 0U;
    /* Configure the PMA */
    ep->pmaadress = (uint16_t)pmaadress;

    // correct PMA BTABLE
    uint32_t *btable = (uint32_t *) USB_PMAADDR; // Test this.
    if (ep->is_in) {
        btable[ep->num * 4] = pmaadress;
    }
  }

The value at pam[12] does get set, but it later gets overwritten:

解决方案

__HAL_RCC_USB_CLK_ENABLE() enables clocks for the USB block. Before it is enabled, all peripheral locations are read as zeroes. After clock is enabled, the actual PMA content becomes visible, whatever was written there before reset or random garbage left after the power up. So executing __HAL_RCC_USB_CLK_ENABLE() has nothing to do with your problem.

I don't know where the TX buffer address for endpoint 3 gets overwritten, but I guess it is the Cube sets it when it decides to send data on the endpoint. I am not familiar with the Cube, does it have an API to send a USB packet?

Also, double-check that your pma array has the right definition. On F1 and I likely F3, there is a 2-byte value at each of the 32-bit location.

UPD: Sorry, I saw this question first, but your real problem is why TX addr gets overwritten or not set up correctly.

这篇关于在HAL_PCD_MspInit()中执行__HAL_RCC_USB_CLK_ENABLE()宏时，是什么初始化STM32 USB BTABLE的内容?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！