[korotaev 0]

MX_Cube v.6 после генерации кода в файл usbd_conf.c  вставляет функции

USBD_StatusTypeDef USBD_LL_Transmit(USBD_HandleTypeDef *pdev, uint8_t ep_addr, uint8_t *pbuf, uint32_t size)

и

USBD_StatusTypeDef USBD_LL_PrepareReceive(USBD_HandleTypeDef *pdev, uint8_t ep_addr, uint8_t *pbuf, uint32_t size),

на которые выдаётся ошибка «Конфликт типов».

 

Где-то эти функции имеют аргумент size с типом uint16_t. Кстати, в примерах эти функции также имеют тип uint16_t аргумента size.

Перед компиляцией приходится тип аргумента size менять c  uint32_t  на uint16_t. Иначе ошибка.

 

Может кто знает, что надо сделать чтобы MX_CUBE генерировал эти функции с типом uint16_t? Я лично не смог найти.

Приходится сейчас довольно часто генерировать код добавляя разную периферию. Просто уже устал делать эту замену в этих функциях.

[Xenia 45]

Эти функции определены здесь:

\Middlewares\ST\STM32_USB_Device_Library\Core\Inc\usbd_core.h

а  используются тут:

\Middlewares\ST\STM32_USB_Device_Library\Core\Src\usbd_ioreq.c

а ваши расхождения можно объяснить только тем, что Inc и Src были выбрали из разных источников.

Определитесь с источником и возьмите usbd_core.h и usbd_ioreq.c из одного места.

[korotaev 0]

Xenia, спасибо за ответ.

Не смог пофиксить проблемку.

Я использую STM32CubeMX для получения скелета программы. Ранее не использовал его вообще. Если бы не необходимость перехода с STM32F4.. на STM32H7.., то вообще бы его не использовал.

STM32CubeMX генерирует самодостаточный проект (скелет программы) со всеми необходимыми файлами и использует для этого некий репозитарий (package). Что-то указать ещё нет возможности.  У меня для STM32H7.. используется репозитарий STM32Cube_FW_H7_v1.7.0. В папке STM32Cube_FW_H7_V1.7.0\Middlewares\ST\STM32_USB_Device_Library\Core\Src находятся файлы с описанными функциями, где аргументы имеют тип uint16_t, а не uint32_t. В папке INC тоже с типами uint16_t.

Откуда «рождаются»

USBD_StatusTypeDef USBD_LL_Transmit(USBD_HandleTypeDef *pdev, uint8_t ep_addr, uint8_t *pbuf, uint32_t size)

и

USBD_StatusTypeDef USBD_LL_PrepareReceive(USBD_HandleTypeDef *pdev, uint8_t ep_addr, uint8_t *pbuf, uint32_t size)

понять не могу.

 

Приходится постоянно править uint32_t size на uint16_t size.

[Xenia 45]

4 часа назад, korotaev сказал:

Я использую STM32CubeMX для получения скелета программы. Ранее не использовал его вообще. Если бы не необходимость перехода с STM32F4.. на STM32H7.., то вообще бы его не использовал.

STM32CubeMX генерирует самодостаточный проект (скелет программы) со всеми необходимыми файлами и использует для этого некий репозитарий (package). Что-то указать ещё нет возможности.  У меня для STM32H7.. используется репозитарий STM32Cube_FW_H7_v1.7.0. В папке STM32Cube_FW_H7_V1.7.0\Middlewares\ST\STM32_USB_Device_Library\Core\Src находятся файлы с описанными функциями, где аргументы имеют тип uint16_t, а не uint32_t. В папке INC тоже с типами uint16_t.

Подобные случаи бывают, когда что-то из Middlewares спускают в проект в виде копии, а затем репозитарий обновляется, и в результате h-файл перестает соответствовать c-файлу. Например, в случае, когда c-файл спустили в проект для модификации, а комплиментарный ему h-файл остался в папке Middlewares. Я сама раза два на это натыкалась, когда переходила на новую версию репозитария. Кстати, STM32Cube_FW_H7_V1.7.0 на сегодняшний день не последний - появился STM32Cube_FW_H7_V1.8.0. А поскольку вам все равно решать свою проблему хирургическим путем :), то имеет смысл перейти на более свежую версию, тем более что H7 - довольно новое семейство и в коде для него всё еще происходят подвижки, тогда как для F4 код уже устаканился. Но пока я опишу, что предлагаю вам сделать на вашей версии STM32Cube_FW_H7_V1.7.0.

1. Вы не пишите, какой компилятор используете, но полагаю, что вы умеете определять, откуда ваш проект берет файлы. Проверьте их источник.

Это может быть глобальный источник:

C:\Users\...\STM32Cube\Repository\

или локальный:

ваш проект\Drivers\

ваш проект\Middlewares\

На худой случай можно посмотреть в файл .mxproject, но лучше все-таки проверить проект компилятора, а не Куба.

Будет лучше, если проект у вас окажется локальным - тогда несмотря на больший его объем, он будет независим от версии репозитария, проинсталлированного на данный компьютер.

2. Если проект у вас локальный, то проверьте совпадение (по размеру и дате) файлов из локального репозитария с файлами из глобального:

C:\Users\...\STM32Cube\Repository\STM32Cube_FW_H7_V1.7.0\Drivers\STM32H7xx_HAL_Driver\

C:\Users\...\STM32Cube\Repository\STM32Cube_FW_H7_V1.7.0\Drivers\CMSIS\

C:\Users\...\STM32Cube\Repository\STM32Cube_FW_H7_V1.7.0\Middlewares\ST\

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

3. При желании перейти сразу на новую версию STM32Cube_FW_H7_V1.8.0 делаете всё то же самое, только сверх того в файле *.ioc  замените строку

ProjectManager.FirmwarePackage=STM32Cube FW_H7 V1.7.0

на

ProjectManager.FirmwarePackage=STM32Cube FW_H7 V1.8.0

Тогда при запуске Куба он сам предложит залить новый репозиторий, если дать на то согласие.

[korotaev 0]

17 hours ago, Xenia said:

1. Вы не пишите, какой компилятор используете, но полагаю, что вы умеете определять, откуда ваш проект берет файлы. Проверьте их источник.

Это может быть глобальный источник:

C:\Users\...\STM32Cube\Repository\

или локальный:

ваш проект\Drivers\

ваш проект\Middlewares\

На худой случай можно посмотреть в файл .mxproject, но лучше все-таки проверить проект компилятора, а не Куба.

Будет лучше, если проект у вас окажется локальным - тогда несмотря на больший его объем, он будет независим от версии репозитария, проинсталлированного на данный компьютер.

 

Компилятор Keil. Проект локальный, как я ранее писал со всеми необходимыми файлами. После генерации кода CubeMX полностью обновляет все файлы за исключением текста в скобках user code.  uint32_t появляется также при создании НОВОГО проекта.  

 

...2. Если проект у вас локальный, то проверьте совпадение (по размеру и дате) файлов из локального репозитария с файлами из глобального:...

Файлов usbd_conf в глобальном репозитарии нет. Есть файлы usbd_conf_template. Там аргумент size имеет тип uint16_t. Файлы usbd_conf появляются в локальном проекте после генерации кода и c uint32_t.

 

...3. При желании перейти сразу на новую версию STM32Cube_FW_H7_V1.8.0...

Обновляю до 1.8. 

 

 

Изменено 4 декабря, 2020 пользователем korotaev

[korotaev 0]

Новый проект сгенерированный CubeMX c  STM32Cube_FW_H7_V1.8.0 откомпилировался без ошибок, хотя "функции" в файле usbd_conf имеют uint32_t.

Проекты уже имеющиеся после генерации кода с новой STM32Cube_FW_H7_V1.8.0 выдаёт сообщение, что генерация кода выполнена успешно, но есть проблемы с созданием библиотеки и копии.

Думаю свою проблему решу. Вопрос снимаю. 

Xenia, Вам персональное спасибо. 

[Xenia 45]

9 часов назад, korotaev сказал:

Проекты уже имеющиеся после генерации кода с новой STM32Cube_FW_H7_V1.8.0 выдаёт сообщение, что генерация кода выполнена успешно, но есть проблемы с созданием библиотеки и копии.

Значит, не все скопировали. У меня тоже так бывает, когда-то что-то недокопировала.

 

9 часов назад, korotaev сказал:

Новый проект сгенерированный CubeMX c  STM32Cube_FW_H7_V1.8.0 откомпилировался без ошибок, хотя "функции" в файле usbd_conf имеют uint32_t.

Но так и должно быть. В свежих версиях
STM32Cube_FW_F4_V1.25.1

и

STM32Cube_FW_H7_V1.8.0

в файле usbd_core.h функции USBD_LL_Transmit и USBD_LL_PrepareReceive определены именно так - с параметром uint32_t, и это правильно.

А если у  вас не так, то значит где-то тащите за собой хвост из старых версий, когда тот параметр был uint16_t. Мне странно, что это место в своем же проекте вы никак не можете найти.

 

А пока я могу лишь только посоветовать вам обновить заодно и версию CubeMX - ныне ее последняя версия 6.10. Возможно, что это она виновата.