Loading...
 

Zephyr project on STM32

   Zephyr Workbench, a VSCode extension to manage Zephyr on STM32.
It enables users to easily create, develop, and debug Zephyr applications.
Main features:
  • Install host dependencies.
  • Import toolchain and SDK.
  • Create, configure, build and manage apps.
  • Debug STM32.
You can directly download it from the VSCode marketplace
For more details, visit the Zephyr Workbench

System Workbench for STM32

Forum List Topic List

[ prev topic | next topic ]  

STM32F107 and assembler errors?

Posted by awestermann on 2016-08-22 23:03

Currently I am working on a project using the STM32F107 and the System Workbench. I have already worked on another project with a STM32F407 and the System Workbench before, so I know a little bit how to find my way around.

So far everything was working fine.

However, I am experiencing some (for me) unexpected behavior which I want to understand rather than just live with it :-)

The OpenSTM32 IDE version I am using is:
OpenSTM32 IDE 1.10.0.201607251855 fr.ac6.feature.mcu.ide.feature.group Ac6
ARM Compiler:
ARM Compiler for MCU (for Windows 32 bits) 1.7.0.201602121829 fr.ac6.feature.mcu.externaltools.armnone.win32.feature.group Ac6

There are actually 2 things:

  • (Not completely reproducable): When generating code from the STM32cubeMX, everything compiles fine etc. However, when moving around the instruction “__HAL_RCC_PLLI2S_ENABLE();” (generated by the STM32CubeMX), an error appears saying: “Error: selected processor does not support `rbit r0,r0’ in Thumb mode”. However, that error was not there at the start of the project, everything compiled just fine. It was only after I converted the project to C++ usage that this appeared. Currently I have worked around the problem by just using bit-or instructions instead of using the predefined macro.
  • Completely reproducable: When using the “set_BASEPRI()” and “get_BASEPRI()” macros (defined in cmsis_gcc.h), errors like “Error: selected processor does not support `mrs r3,basepri’ in Thumb mode” are produced.


Obviously, I can work around the last problem as well, however, it was bothering me that I don’t really understand why those errors are showing up. Maybe there is a perfectly suitable explanation and I’m just not getting it :-)
Any hint is greatly appreciated.

Reads: 8982
Link
Posted by awestermann on 2016-10-04 13:53
  • bump*

Anyone got an idea about that?

Link

Posted by Vetch on 2016-10-10 09:00

Hello,
I tried to reproduce the issue you faced : I generated code from CubeMX for a STM32F107VCT + EVAL board but I didn’t get the any error.
Please, may you give few more details on the CubeMX project (then I will reproduce it)? Thank you.

Link

Posted by awestermann on 2016-10-14 16:36

Hey Vetch,

The processor I used was the STM32F107RBTx, now I had to switch to the STM32F107RCTx because of flash-size issues. Thus I had to create a new project (I used CubeMX for that, just as you did). I dragged all of the old sourcecode into the new project.

However, the old project has been converted from a C project to a C++ project using the second approach shown here http://www.openstm32.org/tiki-view_forum_thread.php?forumId=7&comments_parentId=1244&highlight=convert%20c%2B%2BQuestion (editing the .project file).
This time I chose to go with right click -> Convert to C++.

That somehow fixed this kind of behavior. I can now use the instructions shown above without generating errors.

So, either it has been caused by the STM32F107RBTx vs. STM32F107RCTx, or it has been caused by the way I converted the project to a C++ project. By now, everything works :-)

Link