Bringing up a SAM4S with Keil and FreeRTOS, Failure in XPortStartScheduler with configPRIO_BITS check
Hello all,
I have previously used FreeRTOS successfully for a project targeting the SAM4E16E. I’m now doing a project on a SAM4S2A and having some trouble. I’m using Keil uVision V5.27.1.0.
I noticed that recent uVision project wizards had the ability to include FreeRTOS, so I did that when configuring the project, rather than using the manually-configured version as in the older project. It seems like there is some conflict in how the priority bits are defined.
I’m getting a failure in xPortStartScheduler, particularly the line:
configASSERT( ( portMAXPRIGROUPBITS – ulMaxPRIGROUPValue ) == configPRIO_BITS );
The version of port.c I’m using comes from:
Keilv5ARMPACKARMCMSIS-FREERTOS10.2.0SourceportableGCCARMCM3port.c
I’m not sure this is the right version, but the values in the CM4 versions looked similar.
portMAXPRIOGROUPBITS is defined as 7
The version of FreeRTOSConfig.h I’m using was created under RTERTOSFreeRTOSConfig.h and defines configPRIO_BITS like this:
~~~
Bringing up a SAM4S with Keil and FreeRTOS, Failure in XPortStartScheduler with configPRIO_BITS check
Are you saying that if configPRIOBITS is manually set to 4 in
FreeRTOSConfig.h then the configASSERT() passes? If so then it does
seem to be an include dependency issue somewhere – to which I would ask
have ARM changed the source files in any way? FreeRTOS.h must always be
included first, then the header file for the APIs you are using (task.h,
queue.h, eventgroups.h, etc.) – and never include FreeRTOSConfig.h
manually as it is brought in at the right time by FreeRTOS.h.
If it is not a dependency issue, and port.c is genuinely using
__NVICPRIOBITS and not the hard coded 3, and __NVICPRIORBITS is set
correctly for the device (more than once found that not to be the case),
then most likely cause is that somewhere in the start up code the
priority bits are being split between preemption and sub priorities.
That is normal on STM32, where has to be manually switched back to all
preemption priority and no sub priority (what it needs to be), but I’ve
never seen anything like that on a SAM device.
Bringing up a SAM4S with Keil and FreeRTOS, Failure in XPortStartScheduler with configPRIO_BITS check
Hi Richard,
Are you saying that if configPRIO_BITS is manually set to 4 in FreeRTOSConfig.h then the configASSERT() passes?Testing that theory now….
Bringing up a SAM4S with Keil and FreeRTOS, Failure in XPortStartScheduler with configPRIO_BITS check
Hmmm. If I make that change, it seems to fail a few lines earlier, line 276 in port.c:
~~~
/* The kernel interrupt priority should be set to the lowest
priority. */
configASSERT( ucMaxPriorityValue == ( configKERNEL_INTERRUPT_PRIORITY & ucMaxPriorityValue ) );
~~~
ucMaxPriorityValue is 0xF0 and it looks like configKERNELINTERRUPTPRIORITY is defined in FreeRTOSConfig.h as:
~~~
define configKERNELINTERRUPTPRIORITY (configLIBRARYLOWESTINTERRUPTPRIORITY << (8 – configPRIOBITS))
~~~ Looks like I also may need to change need to change configLIBRARYLOWESTINTERRUPTPRIORITY to 0x0F if I’m going to force configPRIOBITS to 4? That seems to result in passing all the asserts, and I see that my initial startup task is executing, but it looks like the first task I launch from there is not executing, so I’m looking into that now.Bringing up a SAM4S with Keil and FreeRTOS, Failure in XPortStartScheduler with configPRIO_BITS check
It appears that my first task is never returning from its first attempt at xSemaphoreTake(). It seems that it is never timing out and getting stuck in portSUPPRESSTICKSAND_SLEEP(). Looking into that.
Bringing up a SAM4S with Keil and FreeRTOS, Failure in XPortStartScheduler with configPRIO_BITS check
Is the tick interrupt executing? If you pause the debugger and inspect
the variable xTickCount is it increasing at the expected rate? If not,
timeouts won’t happen.
Bringing up a SAM4S with Keil and FreeRTOS, Failure in XPortStartScheduler with configPRIO_BITS check
I will continue to look into it tomorrow. I guess I expected the Keil project configurator to produce settings for this project that would support bringing up and running at least a couple of my tasks (ported from my previous project also for the SAM4 family). But that does not seem to be the case, so I guess I have to step through everything…
Bringing up a SAM4S with Keil and FreeRTOS, Failure in XPortStartScheduler with configPRIO_BITS check
No, it looks like xTickCount is not increasing, although oddly it appears to be going back and forth between 0 and 1.
I also had to fix a problem where the default heap size was only 4096 bytes, which seems a little ridiculous, and meant that I couldn’t launch more than one task.
Bringing up a SAM4S with Keil and FreeRTOS, Failure in XPortStartScheduler with configPRIO_BITS check
Well, I spoke too soon. It does seem like SysTick is running. It is hard to get a breakpoint and watch on xTickCount to work reliably, but the system peripheral viewer in the uVision IDE shows it is running. Reading the datasheet last night, I thought it might be stopped because it might be configured by default to use an external crystal, and I’m using the embedded 4/8/12MHz fast RC oscillator. That can’t be the case because it looks like it is set up by default to use the processor clock. However, I’m still seeing the execution get stuck and never return from the first call to vTaskDelayUntil().
I’m going to dig into my clock configuration, and see if I can get the same clock onto a microcontroller pin so I can verify the speed.
Thanks for your suggestions!
Bringing up a SAM4S with Keil and FreeRTOS, Failure in XPortStartScheduler with configPRIO_BITS check
Sorry – its not clear – if I understand you correctly then SysTick is
running but xTickCount is not incrementing. If that is the case then it
is probably because the FreeRTOS systick interrupt handler is not
installed. Search for vPortSVCHandler on this page
https://www.freertos.org/FAQHelp.html
Bringing up a SAM4S with Keil and FreeRTOS, Failure in XPortStartScheduler with configPRIO_BITS check
I don’t think it is that. The macros xPortSysTickHandler, etc. are defined in my FreeRTOSConfig and I can see in the link map that the SysTick from port.c is included:
~~~
startupsam4s.o(RESET) refers to port.o(i.SysTickHandler) for SysTickHandler
…
SysTickHandler 0x00400751 Thumb Code 46 port.o(i.SysTick_Handler)
~~~
I was also able to catch a breakpoint in the SysTick interrupt handler xPortSysTickHandler(), but they don’t seem to be happening consistently, so I think it may be a clocking issue.
Bringing up a SAM4S with Keil and FreeRTOS, Failure in XPortStartScheduler with configPRIO_BITS check
Looks like the tick problem was the clocking configuration for master clock (MCK). I’ve got task switching and timeouts going now and SysTick is coming from the internal RC oscillator which is what I want for my prototype board. Thanks for your help!