2021-06-30 06:47 AM
the project is created from CubeMX, STM32F091CCT
Solved! Go to Solution.
2021-07-06 06:36 AM
There is no other instance of _sbrk (in syscalls.c. or sysmem.c). Any away, I don't want to change sysmem.c and syscalls.c, since they are standard files created by CubeMX. I never had to mess with these files in the past projects. Somehow, sysmem.c and syscalls.c were corrupted. The fix is to prevent sysmem.c and syscalls.c getting corrupted.
I don't have a fix, just a work around. The work around is (as posted in my case in ST support site):
2021-06-30 08:47 AM
Hello @Community member,
Check if you have have another instance of _sbrk somewhere, in the files (syscalls.c. or sysmem.c).
So, you should delete it.
If you still have issues, don't hesitate to come back to the Community.
When your question is answered, please close this topic by choosing Select as Best. This will help other users find that answer faster.
Imen
2021-07-05 06:15 AM
Hi @Community member ,
Do you have still this problem to solve?
If yes, please provide more information (or screenshot) to understand the cause.
Please share the update if your issue is solved, and select the best answer, this will help other users to find the answer faster.
Imen
2021-07-06 06:36 AM
There is no other instance of _sbrk (in syscalls.c. or sysmem.c). Any away, I don't want to change sysmem.c and syscalls.c, since they are standard files created by CubeMX. I never had to mess with these files in the past projects. Somehow, sysmem.c and syscalls.c were corrupted. The fix is to prevent sysmem.c and syscalls.c getting corrupted.
I don't have a fix, just a work around. The work around is (as posted in my case in ST support site):
2021-07-06 06:54 AM
Hi @Community member ,
Thanks for your update, I'm glad to know you overcame this problem.
Imen
2021-07-06 07:00 AM
I hope ST continue to find root cause of this problem to prevent corruptions within CubeMX and CubeIDE.