cancel
Showing results for 
Search instead for 
Did you mean: 

STM32L4R5 Nucleo FreeRTOS Broken

DM.7
Associate III

Hi,

The auto generated code does not work.

STM32CubeIDE version 1.7.0

Create a new STM project -> board selector -> NUCLEO-L4R5ZI

Project Name: rtostest

Firmware Package: V1.17.0

Initialize all peripherals with their default mode - Yes

Middleware -> FREERTOS -> CMSIS_V2

Save

Ignore warnings about timebase and newlib, yes to continue

Make

Debug

It gets to line 107 of main.c, MX_USB_OTG_FS_PCD_Init() and does not return. Looping between addresses 0x1fff16d2 to 0x1fff16e4

Stop debugging, open ioc file

Connectivity -> USB_OTG_FS -> Disable

Save, ignore warnings

Make, debug

When it starts the kernel (osKernelStart()), it again goes to looping between addresses 0x1fff16d2 to 0x1fff16e4. A breakpoint in the default task never triggers.

Stop debugging, open ioc file

Middleware -> FREERTOS -> Advanced Settings -> USE_NEWLIB_REENTR   Enabled

Save, ignore timebase warning

Same behaviour, looping between addresses 0x1fff16d2 to 0x1fff16e4. A breakpoint in the default task never triggers.

Address the timebase warning by changing the timebase source

System Core -> SYS -> Timebase Source -> TIMXX

Going through every timer in the list, produces the same result - not returning from HAL_Init and looping between addresses 0x1fff16d2 to 0x1fff16e4

I have tried this on 2 different boards and get the same results

1 ACCEPTED SOLUTION

Accepted Solutions
6 REPLIES 6

Hello @DM.7​ ,

Could you please try an example provided under the L4 firmware package (Path: ProjectsNUCLEO-L4R5ZI\Applications\USB_Device)

Please let me know if it works well for you.

Thanks in advance.

BeST Regards,

Walid

DM.7
Associate III

Hello Walid,

The USB issue in my above description can be solved by selecting the appropiate USB_DEVICE middleware in the ioc file. This will still get to the point where no tasks are executing. Neither of the examples for USB devices use FreeRTOS, and they appear to work.

The FreeRTOS example sets all IO to GPIO analog, including the debug pins, so I assume that is why the debugger gets disconnected. Removing that function shows that the FreeRTOS threads are working.

Does this mean that the CubeMX output cannot be used and all work needs to be derived from those examples?

Many thanks,

Dan

Hello @DM.7​ ,

Can you please share your ioc file for further check?

Thanks in advance.

BeST Regards,

Walid

DM.7
Associate III

Attached is the IOC file generated with the USB device package included.

When debugging, it never gets to the function to initialise the USB which is called inside the default FreeRTOS task

DM.7
Associate III

Hello,

Have you managed to recreate this issue?

Many thanks,

Dan

DM.7
Associate III