CubeMXIDE 1.14.0 bug report
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-12-29 7:12 AM
- Once emdos has been selected, while the selection can be changed and emdos can be deselected: The program always puts in a library. I:LibosT8MLVHLSP.a Since this file does not exist, compilation fails. Processor selection is L562
- Library path added : Middlewares/Third Party/Segger RTOS EMBOS/embos/Library/GCC
- Source locations include ThreadX (NOT USED!), and embOS (NOT USED)
- Making changes to the program properties in the IOC file regenerates these choices. Which then must be removed manually.
- ThreadX may never have been part of this project, embOS was tried, but fails compilation for lack of proper symbols, and then removed.
- Labels:
-
Bug-report
-
STM32CubeIDE
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-01-03 5:13 AM
Hello @Harvey White and welcome to the community,
I have tried to reproduce the problem with stm32CubeIDE 1.14.0 and stm32CubeMX standalone 6.10.0. I followed the steps below:
1- Create an stm32project for stm32L562
2- Activate I-CUBE-embOS pack
3- Enable RTOS embOS
As a result there is an added library libosT8MLVHLD.a under the path (Middlewares/Third Party/Segger RTOS EMBOS/embos/Library/GCC).
While emdos is deselected, there are no compilation failures and there is no ThreadX or embOS includes in the source location.
Can you provide any additional information or the IOC file to reproduce the problem?
Thanks,
Rim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-01-03 7:02 AM
There is something odd in my system that causes this kind of thing. The errors are frequently difficult (if not impossible) to reproduce.
I'd suggest that you've done exactly what was done by the people testing the software, which may not reproduce all the steps.
Take a FreeRTOS enabled project, then disable it, and enable emDOS, do a compile or so (and see if there are compile errors with some sort of stack variable missing), then disable emDOS, and re-enable FreeRTOS. See what happens.
The above is a more reasonable test scenario to me. I'll include the IOC file.
Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-01-10 2:14 AM
Hello @Harvey White ,
The compile error problem has been reproduced with "embOS" . An internal ticket ID 170279(This is an internal tracking number and is not accessible or usable by customers) has already been submitted to escalate this issue internally to the STM32CubeIDE team.
Thank you for your contributions,
Rim.
