When I import and then try to build the above demo project I get an error message stating that I need to run the directory structure build batch file first which I did in fact do. The ***FreeRTOSSource*** subdirectory is created in the project directory and files appear within the subdirectories confirming that the batch process completed OK.
If I comment out the error trap code and re-build there are 53 errors reported.
Three errors similar to this:
lo register required -- `ldmia r0!,{r4-r11}'
Fifty errors similar to this:
selected processor does not support `dsb ' in Thumb mode
Is this the proper forum to report Demo project problems to? If not please direct me to where I can get support for this.
This looks like a mismatch between the MCU architecture the assembly
code is written for, and the MCU architecture the compiler is being told
it is building code for. In other words, it looks like the compiler’s
command line options are wrong. I’m not sure why this would be -
perhaps it is an incompatibility in TrueStudio versions in regards to
how it saves options in its project. Check the command line generated
by the tool, which you will be able to see as the project builds, and
also look at the target settings in the tool itself to ensure it matches
the target you are building for (it looks like it is trying to build for
a Cortex-M0).
Thank you for your support! It turned out to be a target mismatch between
TrueStudio and the demo. I had presumed it was setup by the demo
but found I needed to specify the specific STM32 MPU within
the TrueStudio project settings.
However once I corrected the MPU ID it still would not build. I got two new
errors similar to the one below. With an online search I discovered a fix
this info may be of interest to you:
“register may not be same – ‘strexb r3,r2,[r3]’”
The modification described at the link below fixed the problem. The
procedure involves modifying one of the core files within the demo
project directory:
It now builds without error for the stm32f103c8t6 MPU but I wonder if
this code change is a proper fix for the bug. Note the demo is for a board
equipped with the lesser memory stm32f100 MPU of the same family. I
think unlikely that this error occurred because of the MPU difference
but I suppose possible.
Is the ‘register may not be the same’ error in our port code? Or in a
cmsis file that ships with our demo? I think the latter we don’t use
that asm instruction.