identifier "SystemCoreClock" is undefined

manua wrote on Sunday, September 22, 2019:

Hi,

First attempt at trying FreeRTOS with MDK5. Trying to build add to a sample STM32F334 project that exists;

Created a folder within the existing project, copied relevant FreeRTOS files.

Copied the FreeRTOSConfig.h file from FreeRTOS/Demo/CORTEX_M4F_STM32F407ZG-SK/
Wasn’t very sure whether the stock config file helps.

I get the following build failure.

compiling port.c…
FreeRTOS\portable\RVDS\ARM_CM4F\port.c(712): error: #20: identifier “SystemCoreClock” is undefined
ortNVIC_SYSTICK_LOAD_REG = (
onfigSYSTICK_CLOCK_HZ / configTICK_RATE_HZ ) - 1UL;
FreeRTOS\portable\RVDS\ARM_CM4F\port.c: 0 warnings, 1 error

“.\Objects\Blinky.axf” - 1 Error(s), 0 Warning(s).

Do, I need to tweak the FreeRTOSConfig.h ?

Can somebody suggest what to do ?

Thanks,
Manu

rtel wrote on Sunday, September 22, 2019:

SystemCoreClock is the name of a variable used by CMSIS header files.
If you are using a CMSIS header file for your chip it should be defined
in there, and including the CMSIS header file from within
FreeRTOSConfig.h will fix the issue. Otherwise manually edit
FreeRTOSConfig.h to replace the reference to SystemCoreClock with
whatever clock speed is used to feed the SysTick timer on your device -
the configCPU_CLOCK_HZ parameter is the one to set.

aggarg-aws wrote on Sunday, September 22, 2019:

The variable SystemCoreClock is exported from stm32 system file which usually contains SystemInit and SystemCoreClockUpdate functions. For STM32F334, it should be called system_stm32f3xx.c.

You can use STM32CubeMX to generate a MDK5 project for STM32F334 which can be used a starting point.

Thanks.

aggarg-aws wrote on Sunday, September 22, 2019:

I am attaching this MDK5 project for STM32F3348 Discovery board which I generated using CubeMX - if that helps you.

Thanks.

manua wrote on Sunday, September 22, 2019:

Hi Gaurav,

Thanks for sending the CubeMX. But I’ve been using the std peripheral library.
What I did was download FreeRTOS 10.2.1 and then extract the relevant
files into MDK5.

I see that you have an additional freertos.c and a main.c, which
probably uses RTX ?
(cmsis_os.h).
The project builds, but I’m confused with all the mix in there

Reading documentation with MDK5, makes it even more confusing with
CMSIS v1, v2 and so on.

Thanks,
Manu

On Mon, Sep 23, 2019 at 1:57 AM Gaurav Aggarwal
aggarg-aws@users.sourceforge.net wrote:

I am attaching this MDK5 project for STM32F3348 Discovery board which I generated using CubeMX - if that helps you.

Thanks.

Attachments:

stm32f334.zip (24.1 MB; application/x-zip-compressed)


identifier “SystemCoreClock” is undefined


Sent from sourceforge.net because you indicated interest in SourceForge.net: Log In to SourceForge.net

To unsubscribe from further messages, please visit SourceForge.net: Log In to SourceForge.net

manua wrote on Sunday, September 22, 2019:

Hi Gaurav, Richard,

I have the variable in system_stm32f30x.c in my existing test project
uint32_t SystemCoreClock = 72000000;

In FreeRTOSConfig.h, I see the following:

#define configCPU_CLOCK_HZ ( SystemCoreClock )

Wondered whether manually copy-paste would be the right option.
Or whether anything else was intended in the first place

Being new to FreeRTOS, thought the best would be to ask.

Thanks,
Manu

On Mon, Sep 23, 2019 at 1:50 AM Gaurav Aggarwal
aggarg-aws@users.sourceforge.net wrote:

The variable SystemCoreClock is exported from stm32 system file which usually contains SystemInit and SystemCoreClockUpdate functions. For STM32F334, it should be called system_stm32f3xx.c.

You can use STM32CubeMX to generate a MDK5 project for STM32F334 which can be used a starting point.

Thanks.


identifier “SystemCoreClock” is undefined


Sent from sourceforge.net because you indicated interest in SourceForge.net: Log In to SourceForge.net

To unsubscribe from further messages, please visit SourceForge.net: Log In to SourceForge.net

manua wrote on Sunday, September 22, 2019:

Hi Richard,

On Mon, Sep 23, 2019 at 1:50 AM Richard Barry
rtel@users.sourceforge.net wrote:

SystemCoreClock is the name of a variable used by CMSIS header files.
If you are using a CMSIS header file for your chip it should be defined
in there, and including the CMSIS header file from within
FreeRTOSConfig.h will fix the issue. Otherwise manually edit
FreeRTOSConfig.h to replace the reference to SystemCoreClock with
whatever clock speed is used to feed the SysTick timer on your device -
the configCPU_CLOCK_HZ parameter is the one to set.

Tried manually editing the variable in FreeRTOSConfig.h, but that does
not appear to make any changes

//#define configCPU_CLOCK_HZ ( SystemCoreClock )
#define configCPU_CLOCK_HZ ( ( unsigned long ) 72000000 )

The same error persists.

Wonder, what I am doing wrong …

Thanks,
Manu

manua wrote on Sunday, September 22, 2019:

Hi Richard,

I am using the STM32F3348-Discovery-FW_V1.0.0 firmware package,
which is centered around the STM32F30x_StdPeriph_Driver package.

The variable’s defined in the system_stm32f30x.c file

The initial thought was whether something else to be done, without
manually editing the file and hence the question in the first place.

Thanks,
Manu

On Mon, Sep 23, 2019 at 1:50 AM Richard Barry
rtel@users.sourceforge.net wrote:

SystemCoreClock is the name of a variable used by CMSIS header files.
If you are using a CMSIS header file for your chip it should be defined
in there, and including the CMSIS header file from within
FreeRTOSConfig.h will fix the issue. Otherwise manually edit
FreeRTOSConfig.h to replace the reference to SystemCoreClock with
whatever clock speed is used to feed the SysTick timer on your device -
the configCPU_CLOCK_HZ parameter is the one to set.


identifier “SystemCoreClock” is undefined


Sent from sourceforge.net because you indicated interest in SourceForge.net: Log In to SourceForge.net

To unsubscribe from further messages, please visit SourceForge.net: Log In to SourceForge.net

aggarg-aws wrote on Sunday, September 22, 2019:

What I did was download FreeRTOS 10.2.1 and then extract the relevant
files into MDK5.

This should work. I just provided that project so that you can see which file is exporting the variable.

Thanks.

manua wrote on Sunday, September 22, 2019:

On Mon, Sep 23, 2019 at 2:37 AM Gaurav Aggarwal
aggarg-aws@users.sourceforge.net wrote:

What I did was download FreeRTOS 10.2.1 and then extract the relevant
files into MDK5.

This should work. I just provided that project so that you can see which file is exporting the variable.

Tried manually editing FreeRTOSConfig.h. But that did not work. Same
build error.

Attaching the project in here.

Thanks,
Manu

aggarg-aws wrote on Sunday, September 22, 2019:

The project you shared does not build because of some hardcoded paths referring to non-existent folder D:\STM32_CMSIS.

Which FreeRTOSConfig.h is your project using and which one are you updating? The only FreeRTOSConfig.h I see in the attachment is in the folder 01_Blinky\FreeRTOS\include which is not edited.

Thanks.

manua wrote on Sunday, September 22, 2019:

On Mon, Sep 23, 2019 at 2:52 AM Gaurav Aggarwal
aggarg-aws@users.sourceforge.net wrote:

The project you shared does not build because of some hardcoded paths referring to non-existent folder D:\STM32_CMSIS.

Which FreeRTOSConfig.h is your project using and which one are you updating? The only FreeRTOSConfig.h I see in the attachment is in the folder 01_Blinky\FreeRTOS\include which is not edited.

I have the std peripheral lib (en.stsw-stm32148.zip) is extracted to

D:\STM32_CMSIS\STM32F3348-Discovery_FW_V1.0.0\

The changes to FreeRTOSConfig.h, I did revert, seeing no difference in
the build error and hence.

the one FreeRTOSConfig.g, that I have is in:
01_Blinky\FreeRTOS\include\FreeRTOSConfig.h

Thanks,
Manu

aggarg-aws wrote on Sunday, September 22, 2019:

The header search path for your project is configured to D:\FreeRTOS\include and I suspect there is a FreeRTOSConfig.h in D:\FreeRTOS\include which is being picked up by the preprocessor.

I updated the header search paths to the following:

.\FreeRTOS\include
.\FreeRTOS\portable\RVDS\ARM_CM4F

In addition, I needed to comment out the SysTick_Handler in Blinky.c to get rid of multiple definition error:

/*void SysTick_Handler(void)
{
	if (sys.delay != 0)
		sys.delay--;

	sys.ticks++;
}*/

Also, I changed the following defines to avoid missing hook functions linker errors:

#define configUSE_IDLE_HOOK				0
#define configUSE_TICK_HOOK				0
#define configCHECK_FOR_STACK_OVERFLOW	0
#define configUSE_MALLOC_FAILED_HOOK	0

After the above changes, the project builds for me.

Thanks.

manua wrote on Sunday, September 22, 2019:

On Mon, Sep 23, 2019 at 3:30 AM Gaurav Aggarwal
aggarg-aws@users.sourceforge.net wrote:

The header search path for your project is configured to D:\FreeRTOS\include and I suspect there is a FreeRTOSConfig.h in D:\FreeRTOS\include which is being picked up by the preprocessor.

I updated the header search paths to the following:

.\FreeRTOS\include
.\FreeRTOS\portable\RVDS\ARM_CM4F

In addition, I needed to comment out the SysTick_Handler in Blinky.c to get rid of multiple definition error:

/*void SysTick_Handler(void)
{
if (sys.delay != 0)
sys.delay–;

sys.ticks++;

}*/

Also, I changed the following defines to avoid missing hook functions linker errors:

#define configUSE_IDLE_HOOK 0
#define configUSE_TICK_HOOK 0
#define configCHECK_FOR_STACK_OVERFLOW 0
#define configUSE_MALLOC_FAILED_HOOK 0

After the above changes, the project builds for me.

The project now builds. Thanks!

I added task.h to Blinky.c, but then I get a red X mark next to the
header include path, which states that it needs the FreeRTOS.h header.

But when the FreeRTOS.h header is included, I see the red X mark next
to FreeRTOS.h which states:
error in include chain (portmacro.h): use of undeclared label ‘basepri’

The build does complete though without any warning or errors though,
Quite weird though.

Did try the delay implementation from FreeRTOS as in

There’s something wrong with the delay, I guess ?

Thanks,
Manu

/**

  • Blinky example
  • Blinks LED @1Hz on PB.6
    */

#include <stm32f30x.h>
#include <stm32f30x_rcc.h>
#include <stm32f30x_conf.h>

#include <FreeRTOS.h>
#include “task.h”

int main(void)
{
GPIO_InitTypeDef gpio_state;
const TickType_t xDelay = 500 / portTICK_PERIOD_MS;

RCC_AHBPeriphClockCmd(RCC_AHBPeriph_GPIOB, ENABLE);        /*

Enable the GPIO_LED Clock */

/* Configure the GPIO_LED pin */
gpio_state.GPIO_Pin    = GPIO_Pin_6;                /* Pin 6        */
gpio_state.GPIO_Mode    = GPIO_Mode_OUT;
gpio_state.GPIO_OType    = GPIO_OType_PP;            /* Push Pull

Output /
gpio_state.GPIO_PuPd = GPIO_PuPd_NOPULL; /
No
Pullup */
gpio_state.GPIO_Speed = GPIO_Speed_50MHz;

GPIO_Init(GPIOB, &gpio_state);                    /* Port B        */

while (1) {
    GPIOB->ODR ^= GPIO_Pin_6;
    vTaskDelay(xDelay);
}

}

rtel wrote on Monday, September 23, 2019:

If I am reading your code correctly then you are attempting to use a
scheduler API function without first starting the scheduler running. I
would highly recommend starting with some of the pre-configured examples
and reading through the free book download available on
https://www.freertos.org/Documentation

manua wrote on Monday, September 23, 2019:

On Mon, Sep 23, 2019 at 8:04 AM Richard Barry
rtel@users.sourceforge.net wrote:

If I am reading your code correctly then you are attempting to use a
scheduler API function without first starting the scheduler running. I
would highly recommend starting with some of the pre-configured examples
and reading through the free book download available on
Free RTOS Book and Reference Manual

Ahh… Without a task, I’ve been delaying the task!

Changed my code, but 2 issues still remain for me to move ahead.

/**

  • Blinky example
  • Blinks LED @1Hz on PB.6
    */

#include <stm32f30x.h>
#include <stm32f30x_rcc.h>
#include <stm32f30x_conf.h>

#include <FreeRTOS.h>
#include “task.h”

void HardFault_Handler(unsigned int *hardfault_args, unsigned int r4,
unsigned int r5, unsigned int r6)
{

while (1);

}

void task_led(void *params)
{
while(1) {
GPIOB->ODR ^= GPIO_Pin_6;
vTaskDelay(500 / portTICK_RATE_MS);
}
}

int main(void)
{
GPIO_InitTypeDef gpio_state;

RCC_AHBPeriphClockCmd(RCC_AHBPeriph_GPIOB, ENABLE);        /*

Enable the GPIO_LED Clock */

/* Configure the GPIO_LED pin */
gpio_state.GPIO_Pin    = GPIO_Pin_6;                /* Pin 6        */
gpio_state.GPIO_Mode    = GPIO_Mode_OUT;
gpio_state.GPIO_OType    = GPIO_OType_PP;            /* Push Pull

Output /
gpio_state.GPIO_PuPd = GPIO_PuPd_NOPULL; /
No
Pullup */
gpio_state.GPIO_Speed = GPIO_Speed_50MHz;

GPIO_Init(GPIOB, &gpio_state);                    /* Port B        */

xTaskCreate(task_led, "LED", 512, NULL, 1, NULL);
vTaskStartScheduler();

}

Changing the code, I had to modify the Heap size in addition to the
previous changes suggested by Gaurav;
in FreeRTOSConfig.h changed :

//#define configTOTAL_HEAP_SIZE ( ( size_t ) ( 75 * 1024 ) )
#define configTOTAL_HEAP_SIZE ( ( size_t ) (9 * 1024 ) )
/* F334 has 12k + 4k SRAM */

With that change, the build goes ahead.

#1. The MDK5 complains about FreeRTOS.h not found.
(It looks odd, but the build goes ahead without errors or warnings.
I would nevertheless like to fix this issue, though. Does not look nice.)
Attached screenshot. The same issues exists with port.c as well,
wherever FreeRTOS.h
header is included.

Is it possible to fix this issue ? (It’s cosmetic though, but feels
like an irritant)

#2. With the change to TOTAL HEAP SIZE I can see task_led being executed.
The TOTAL_HEAP_SIZE value that appears to work is between (5 * 1024)
and (9 * 1024)
Anything smaller than 5k does not work and anything greater than 9k
does not work.

a) Does that mean that FreeRTOS Kernel is consuming 5k ?
b) the F334 has about 12k SRAM, I should be able to use it as well ?

Thanks,

rtel wrote on Monday, September 23, 2019:

Please read the book as per the link in my previous post - it describes
how RAM is used - you can also check this FAQ
https://www.freertos.org/FAQMem.html - I could repeat the information
here but prefer just to link you to where the information is already
available.

manua wrote on Monday, September 23, 2019:

Thanks for the link. The documentation is quite clear and detailed.

Any thoughts, how I can fix the Header issue ?
AFAICS, the path to the FreeRTOS.h header does exist.

Maybe I’m just blind, that I cant see what the problem is in the first place.

Thanks,

On Mon, Sep 23, 2019 at 6:54 PM Richard Barry
rtel@users.sourceforge.net wrote:

Please read the book as per the link in my previous post - it describes
how RAM is used - you can also check this FAQ
FreeRTOS FAQ relating to FreeRTOS memory management and usage. FreeRTOS is an Open Source RTOS Kernel for small embedded systems - I could repeat the information
here but prefer just to link you to where the information is already
available.


identifier “SystemCoreClock” is undefined


Sent from sourceforge.net because you indicated interest in SourceForge.net: Log In to SourceForge.net

To unsubscribe from further messages, please visit SourceForge.net: Log In to SourceForge.net

rtel wrote on Monday, September 23, 2019:

It does not look like a compiler issue to me - as you said the code
builds just fine - most likely the editor is trying to parse your code
in an attempt to be helpful and just getting it wrong. Eclipse is
notorious for this and from your screenshot it looks like Keil is doing
likewise. Your options are to a) ignore it, b) search the options to
turn the feature off, c) search the options to try and tune it up so it
gets it right.