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

Forum List Topic List

You are viewing a reply to [solved] Symbol 'SysTick_IRQn' could not be resolved  

Symbol 'SysTick_IRQn' could not be resolved

Posted by mdundas on 2016-04-15 17:25
One of my machines doesn’t recognize Systick_IRQn, one setup does. Not sure if a header has been dropped in an update. Quick fix (patch) replace Sytick_IrQn with -1 . That is the Cortex M4 Systick processor exception number.
Reads: 6551
Link
Posted by pipopoplin on 2016-05-15 12:45

If you work with STM32CubeMX you have to check the BOX “Generate peripheral init as a pair ...”.
An ohter issue that i had was, to plug my STM32... over an USB HUB.

Link

Posted by bepi58 on 2016-05-21 18:19

The document behind link pipopoplin provided was very us full for me.
I’m facing the same problem as mdundas does. I assume, that I have a more complex configuration than mdundas has, because I get error messages also for DMA1_Ch2_3_DMA2_Ch1_2_IRQn and DMA1_Ch4_7_DMA2_Ch3_5_IRQn. These are all exception numbers defined in “stm32fxc.h” in the enum “IRQn_Type”.
If I rename “SysTick_IRQn” to something else, for example to “SysTick_IRQn2”, in this header file and in my main.c, the error message disappears for the main.c If document out the definition of “SysTick_IRQn” in the header file, I get the same error message as with the original definition.
I created a new enum. All members worked fine, except “SysTick_IRQn”. The suspicion rose, that “SysTick_IRQn” is multiple defined. I renamed all “stm32fxc.h” files, except the one for my processor type. With the result, that the error for “SysTick_IRQn” was solved. When I gave one of the other “stm32fxc.h” his original name back, the error was also back. I added the following line to this file: #define Foo 1”, right after

  1. ifndef __STM32F038xx_H
  2. define __STM32F038xx_H

and in my main.c: Foo; Foo couldn’t be resolved. Then I added this piece of code right before the enumeration, same result. Now I added Foo = -1, inside the enumeration. Now Foo could be resolved!
My conclusion is, that in some mysterious way this enumeration from any of theses header files in my project find it’s way in to the program building process, even the rest of the file is ignored.
By the way, also the error messages for the other interrupt definitions disappeared.

Link

Posted by bepi58 on 2016-05-21 18:37
Have look at “Forums » System Workbench for STM32» importing a CubeMX project”. The problem is raised by the indexer. Exclude unused header files from the index solved all my problems!
Link
Posted by bluemicat on 2016-05-22 17:26 Germany

Hello @all

I´ve got here the same problem!

Link
Posted by mdundas on 2016-05-24 08:44
If under Project settings, you uncheck “Generate Under Root” before generating your project files it resolves the issue.
Link
Posted by dautrevaux on 2016-05-25 10:06 France

The proper solution, as explained In this FAQ entryQuestion is to uncheck “Index unused headers” from the project properties (or workspace preferences) on the C/C++ Build >> Indexer page.

Unchecking “Renerate under root” just accidentally solve this problem but creates other problems (difficulty to manage your project under SVN or GIT or to add your own source and header files for example) that made it a less-than-optimal solution.

Bernard (Ac6)

Link
Posted by Chudik on 2016-06-11 00:36
I agree with dautrevaux. Unchecking “Generate under root” is just hiding the problem, not really solving it. Source code management in this becomes extemely inconvenient as well as directory structure in the project.
Link
Posted by jo on 2016-07-20 22:37
Thank you, that was the solution.
Link
Posted by Chudik on 2016-06-11 01:35

Seems like the solution with keeping “Generate under root” in place found.

My current project uses L151CCT , but definitely it should work with any other.
So, in my directory ../Drivers/CMSIS/Device/ST/STM32L1xx/Include
only three working files left:

stm32l1xx.h
stm32l151xc.h
system_stm32l1xx.h

All the other headers I moved to archive just in case.
Actually it’s been said above about deleting all the other headers from this directory. I’m not so radical :-)

Definitely this is a bug (not huge, but...), that should be fixed in the next releases.

Happy STMting :-)

Link
Posted by dautrevaux on 2016-06-11 17:35 France

The proper solution, as explained In this FAQ entryQuestion is to uncheck “Index unused headers” from the project properties (or workspace preferences) on the C/C++ Build >> Indexer page. This will automatically do exactly what you have done, but in a lot cleaner way as, as soon as you need one of th eexcluded files it will again be indexed.

Bernard (Ac6)

Link
Posted by Chudik on 2016-06-26 09:05

Bernard,
Hmm... I’m still not too familiar with Eclipse. And, if read how many threads were created about this problem, not too many people know Eclipse in details :-)

And, BTW,
‘’To solve this error, you should request that System Workbench do not parse files that are not used by your project, by opening th eindexer properties dialog (project >> Properties >> C/C++ General >> Indexer) then check the Enable project specific settings checkbox and uncheck the Index unused headers checkbox.

You may also suppress indexing of unused headers for all projects that do not have project-specific indexer settings by modifying the workspace settings at Window >> Preferences >> C/C++ >> Indexer.’’

I could not find anything about indexer at these paths...

Nevertheless, seems like this option set be default now.

Link