Что инициализирует содержимое USB BTABLE STM32, когда макрос __HAL_RCC_USB_CLK_ENABLE() выполняется в HAL_PCD_MspInit()?

Question

Я использовал STM32CubeMX/IDE для создания проекта USB HID для платы STM32F3DISCOVERY.

Регистр USB BTABLE равен нулю, что указывает на то, что BTABLE находится в начале области памяти пакетов.

(Я обнуляю весь PMA при запуске программы, чтобы избежать устаревших значений.)

Незадолго до исполнения __HAL_RCC_USB_CLK_ENABLE макрос (в HAL_PCD_MspInit() в usbd_conf.c) значения BTABLE (начиная с нулевого индекса в PMA:

После выполнения этого макроса значения будут следующими:

Макрос расширяется до:

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 для тестирования использования другой конечной точки. Изменение0x81 к 0x83 в USBD_LL_Init() а также #define HID_EPIN_ADDR недостаточны, чтобы изменить значение pma[12]. Неправильный указатель TX наpma[12] используется, и в wirehark наблюдаются поврежденные данные.)

---

Обновить:

Если я добавлю код для установки вручную 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] устанавливается, но позже перезаписывается:

Answer 1

__HAL_RCC_USB_CLK_ENABLE() включает синхронизацию для USB-блока. Перед включением все периферийные устройства читаются как нули. После включения часов фактическое содержимое PMA становится видимым, независимо от того, что было написано в нем до сброса или случайного мусора, оставшегося после включения питания. Таким образом, выполнение __HAL_RCC_USB_CLK_ENABLE() не имеет ничего общего с вашей проблемой.

Я не знаю, где перезаписывается адрес буфера TX для конечной точки 3, но я предполагаю, что Куб устанавливает его, когда решает отправить данные на конечную точку. Я не знаком с Cube, есть ли у него API для отправки USB-пакетов?

Также дважды проверьте правильность определения вашего массива pma. На F1 и я, скорее всего, F3, есть 2-байтовые значения в каждом из 32-битных местоположений.

UPD: Извините, я впервые увидел этот вопрос, но ваша настоящая проблема в том, почему адрес TX перезаписывается или неправильно настроен.