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

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

0 голосов
/ 28 января 2020

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

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

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

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

BTABLE before

После того, как этот макрос выполнен, значения:

BTABLE after

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

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] i Используемые и поврежденные данные наблюдаются в 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] действительно устанавливается, но позже оно перезаписывается:

BTABLE updated

1 Ответ

1 голос
/ 29 января 2020

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

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

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

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

...