Loading...
 

SW4STM32 and SW4Linux fully supports the STM32MP1 asymmetric multicore Cortex/A7+M4 MPUs

   With System Workbench for Linux, Embedded Linux on the STM32MP1 family of MPUs from ST was never as simple to build and maintain, even for newcomers in the Linux world. And, if you install System Workbench for Linux in System Workbench for STM32 you can seamlessly develop and debug asymmetric applications running partly on Linux, partly on the Cortex-M4.
You can get more information from the ac6-tools website and download (registration required) various documents highlighting:

System Workbench for STM32


Syntax Error for every __weak and __packed

I reported this almost a year back. CDT’s code indexer is still confused about the quotes in the symbols.

Eclipse shows a syntax error every time the __weak or __packed macros are used in ST’s code. The indexer will not properly index the code due to the syntax errors. Searching for references and declarations and whatnot are not properly found, since CDT cannot parse the code due to the the syntax errors.

Rightclick a project and take a look at the compiler settings. In the list of symbols you find this:

__weak="__attribute__((weak))"


So any declaration like

__weak void myFunction();

becomes

"__attribute__((weak))" void myFunction();


That’s a syntax error. Those quotes don’t belong there and should NOT be part of the symbol definition. This needs to be fixed. CDT cannot work properly with those quotes present.

Please fix it, or point me at the code that is involved in generating those quotes. I will fix it and send you a patch.

To make matters worse, SW4STM32 is re-adding those definitions of the quotes are removed. However, these quotes are effectively sabotaging CDT’s Indexer!

Hi,

Thank you for the feedback.

How did you create your project ? I can’t reproduce your issues (Do you use HAL or Stdperiph and for which target board). SW4STM32 does not redefine the __weak attribute, it is already done in the stm32fYxx_hal_def.h in the HAL_Driver.

#if  defined ( __GNUC__ )
  #ifndef __weak
    #define __weak   __attribute__((weak))
  #endif /* __weak */
  #ifndef __packed
    #define __packed __attribute__((__packed__))
  #endif /* __packed */
#endif /* __GNUC__ */


Regard,
Kevin.
(Ac6)

The project has been generated with STMCubeMX 5.2.0. The MCU is a STM32F103C8T6.
The quotes are present in .mxproject - which I believe is imported by SW4STM32?
Or does STMCubeMX touch the .cproject file directly?

Have you been able to reproduce the issue?

Hi,

Sorry for late answer. I could not reproduce your issue.
If I remember well, STMCubeMX was indeed modifying the .cproject file which means each times you regenerated the project, it sets back the problematic quotes. But I think it was fixed on the latest versions of STMCubeMX.

Regards,
Kevin.

I am using STMCubeMX 5.2.0. That is the latest version. The issue persists. I just created a project for the Nucleo L476RG board. And there are the quotes again. Should I attached a screenshot?

I hope you do not expect to see syntax errors reported by GCC. Instead of being properly escaped, the quotes are stripped at some point and they are not passed to GCC. That of course is a bug in itself (!!!). Anyhow, for the CDT Indexer, the quotes are present, hence it cannot understand the syntax and it cannot properly index the files.

The CDT indexer is still being sabotaged - be it by STMCubeMX or by OpenSTM32. This is harmful to the usability of OpenSTM32.

Right after generating a project for the L476RG Nucleo board with STMCubeMX 5.2.0 with default settings, the file .cproject contains the definitions of packed and weak with quotes in them. That is very very wrong.

Do you have contacts at ST? Do I have to report this to ST?
I vaguely recall, that I already did that and they didn’t care. I have to look through their forums.


Hi,

Yes, the issue is in the .cproject generated by STMCubeMX. It is weird because on the older versions, the double quotes were not added and it worked well. I don’t know it was changed.

I think ST forum might have the answer and can report it to the dev team.

Regards,
Kevin.