2021-08-22 02:49 PM
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
Solved! Go to Solution.
2021-09-16 12:39 AM
The cause of this problem is detailed here:
2021-08-25 06:17 AM
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
2021-08-25 07:18 AM
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
2021-08-25 07:55 AM
Hello @DM.7 ,
Can you please share your ioc file for further check?
Thanks in advance.
BeST Regards,
Walid
2021-08-25 08:08 AM
2021-09-06 11:46 PM
Hello,
Have you managed to recreate this issue?
Many thanks,
Dan
2021-09-16 12:39 AM
The cause of this problem is detailed here: