STM32F4 Timer Appears to Break RTOS Scheduler & Task

Hi – I have FreeRTOS implemented in my project. I have a simple task that reads the ADC, which runs with no issues. I now need a more precise HW timer, so I’ve added initialization code into my file to execute a simple timer to which there is a callback for. I have 2 calls to get the timer going, 1 to initialize the timer, the next one to start it. However, it appears that the timer is interfering with FreeRTOS as it will not launch the scheduler (it “beams up” at that point). If I comment out the function call to initialize the timer, FreeRTOS seems to run OK. On the other side, if I initialize & start the timer, and comment out the call to launch the scheduler, the timer & handler appear to function. The base code I am using was generated by STM’s cube utility, and uses the HAL drivers. Also, I’m using IAR EWARM version 7.1 software on an STMF4 Discovery board. Can anyone provide some suggestions as to what is happening? Thank you.

STM32F4 Timer Appears to Break RTOS Scheduler & Task

Which timer are you using? If you are using the SysTick (the timer built into the Cortex-M core) then yes, that will definitely mess up FreeRTOS. You can however hook into the timer interrupt using the vApplicationTickHook() hook function – and use the RTOS tick count as a time base using the xTaskGetTickCount() API function. On the other hand if you are using a peripheral timer then it should have no impact on FreeRTOS – unless you don’t configure the interrupt priorities correctly. If you are using a recent version of FreeRTOS (V7.6.0 or later I think) and have configASSERT() defined then it will automatically check the interrupt configuration for you for compatibility with FreeRTOS. Regards.

STM32F4 Timer Appears to Break RTOS Scheduler & Task

Hi, Did you also try to first start FreeRTOS and after that start the timer interrupt? Secondly, what about the priority of your timer interrupt? When an interrupt has a higher priority than configMAXSYSCALLINTERRUPTPRIORITY, you will run into problems: “ISR safe FreeRTOS API functions must only be called from interrupts that have been assigned a priority at or below configMAXSYSCALLINTERRUPTPRIORITY” And normally: the lower the priority value, the higher its priority. Regards,

STM32F4 Timer Appears to Break RTOS Scheduler & Task

I am using Timer 6. A bit confused (or a lot confused?!?) on something fundamental: on the bottom of FreeRTOSConfig.h, it says: /* IMPORTANT: This define MUST be commented when used with STM32Cube firmware, to prevent overwriting SysTickHandler defined within STM32Cube HAL */ /* #define xPortSysTickHandler SysTickHandler */ What does this mean in terms of using a basic timer such as Timer 6? Also – I’ve found that if I don’t define “xPortSysTickHandler” somewhere, either in the FreeRTOSConfig.h file, or the starup file, the scheduler does not run. So thus the confusion about the commenting out of the line above. So exactly what do I need to do to have FreeRTOS running, and be able to use a HW timer(Timer 6, or whichever) that can run a interrupt handler? Thanks again… BTW – here’s what the top of my current startup file looks like. FreeRTOS runs, but I am unable to generate an interrupt. (“xPortSysTickHandler” is presently UNCOMMENTED in FreeRTOSConfig.h)
    MODULE  ?cstartup

    ;; Forward declaration of sections.
    SECTION CSTACK:DATA:NOROOT(3)

    SECTION .intvec:CODE:NOROOT(2)

    EXTERN  __iar_program_start
    EXTERN  SystemInit
    ;EXTERN xPortPendSVHandler
    ;EXTERN xPortSysTickHandler
    ;EXTERN vPortSVCHandler
    PUBLIC  __vector_table

    DATA
__vectortable DCD sfe(CSTACK) DCD ResetHandler ; Reset Handler
    DCD     NMI_Handler               ; NMI Handler
    DCD     HardFault_Handler         ; Hard Fault Handler
    DCD     MemManage_Handler         ; MPU Fault Handler
    DCD     BusFault_Handler          ; Bus Fault Handler
    DCD     UsageFault_Handler        ; Usage Fault Handler
    DCD     0                         ; Reserved
    DCD     0                         ; Reserved
    DCD     0                         ; Reserved
    DCD     0                         ; Reserved
    ;DCD     vPortSVCHandler           ; SVCall Handler
    DCD     SVC_Handler               ; SVCall Handler        
    DCD     DebugMon_Handler          ; Debug Monitor Handler
    DCD     0                         ; Reserved
    ;DCD     xPortPendSVHandler        ; PendSV Handler
    DCD     PendSV_Handler            ; PendSV Handler        
    ;DCD     xPortSysTickHandler       ; SysTick Handler
    DCD     SysTick_Handler           ; SysTick Handler

     ; External Interrupts
    DCD     WWDG_IRQHandler                   ; Window WatchDog                                        
. . .

STM32F4 Timer Appears to Break RTOS Scheduler & Task

What does this mean in terms of using a basic timer such as Timer 6?
I guess (as I am not familiar with ST’s code yet) that they have defined their own SysTick handler for use by their drivers, and that they call the FreeRTOS SysTick handler from inside that [which maybe a bit backward as normally you would let FreeRTOS handle SysTick then hook code into that using vApplicationTickHook() – but maybe it is done that way so the drivers can run without FreeRTOS too?]. In any case, this should not have any baring on using a peripheral timer, which it seems is what you are doing. FreeRTOS should not affect the use of a peripheral timer, provided you have the interrupt priorities set correction – did you try the think mentioned in my previous post (setting configASSERT())? There is seemingly a contradiction in your post however. The comment you referred to in the FreeRTOSConfig.h file is above a line that maps FreeRTOS’s SysTick handler to the CMSIS name for that handler. Doing that allows you to use an unmodified CMSIS compliant vector table, in which the name of the handler is SysTick_Handler. However the vector table you have posted installs the FreeRTOS name directly, which given what the comment says I think must be a mistake. I think there is a mismatch between your application code and your start up/vector table code. Did you get them both from the same place? Regards.

STM32F4 Timer Appears to Break RTOS Scheduler & Task

Hi, and thank you again for bearing with me on this. A lot of pain with the STM HAL library stuff…Yes, I agree and understand what you are seeing/saying from the above. It appears that way as I was modifying things to see if I could get it to work, but essentially, here’s what I did. I used STM’s cube to generate a timer example with FreeRTOS “middlewares” as they call it. All generated examples now use the HAL calls, which are poorly documented and has no example of what the steps are to set up a timer with an interrupt handler. To answer your question:the define for configASSERT is NOT commented and should be callable, but have not seen this happen. In any case, I took the FreeRTOSConfig.h file, and the “.s” startup file, and planted them into my code, including timer initialization routine they had. In their example, I can breakpoint the call to the handler. With identical code in mine, it does not want to break. So, I guess the above is not really a question (timer setup) for this forum. The question is, will using FreeRTOS “xPortSysTickHandler” interfere with the peripheral timer (Timer 6)? (I would say not from your comments so far) Below is what my startup file NOW looks like, and below that is the FReeRTOSConfig.h. If I comment OUT the define for the xPortSysTickHandler, as shown, the scheduler will not run. If I need to do some detailed reading to understand what’s going on fully, please point me to where that is. I’ve already successfully installed and ran FreeRTOS8 on a CortexM3 LPC1768, and have peripheral interrupts there. Never had these problems….no hair left on head… startup file code slice
   MODULE  ?cstartup

    ;; Forward declaration of sections.
    SECTION CSTACK:DATA:NOROOT(3)

    SECTION .intvec:CODE:NOROOT(2)

    EXTERN  __iar_program_start
    EXTERN  SystemInit
    PUBLIC  __vector_table

    DATA
__vectortable DCD sfe(CSTACK) DCD ResetHandler ; Reset Handler
    DCD     NMI_Handler               ; NMI Handler
    DCD     HardFault_Handler         ; Hard Fault Handler
    DCD     MemManage_Handler         ; MPU Fault Handler
    DCD     BusFault_Handler          ; Bus Fault Handler
    DCD     UsageFault_Handler        ; Usage Fault Handler
    DCD     0                         ; Reserved
    DCD     0                         ; Reserved
    DCD     0                         ; Reserved
    DCD     0                         ; Reserved
    DCD     SVC_Handler               ; SVCall Handler        
    DCD     DebugMon_Handler          ; Debug Monitor Handler
    DCD     0                         ; Reserved
    DCD     PendSV_Handler            ; PendSV Handler        
    DCD     SysTick_Handler           ; SysTick Handler

     ; External Interrupts
FreeRTOSConfig.h code slice
/* The lowest interrupt priority that can be used in a call to a "set priority"
function. */
#define configLIBRARY_LOWEST_INTERRUPT_PRIORITY   15

/* The highest interrupt priority that can be used by any interrupt service
routine that makes calls to interrupt safe FreeRTOS API functions.  DO NOT CALL
INTERRUPT SAFE FREERTOS API FUNCTIONS FROM ANY INTERRUPT THAT HAS A HIGHER
PRIORITY THAN THIS! (higher priorities are lower numeric values. */
#define configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY 5

/* Interrupt priorities used by the kernel port layer itself.  These are generic
to all Cortex-M ports, and do not rely on any particular library functions. */
#define configKERNEL_INTERRUPT_PRIORITY        ( configLIBRARY_LOWEST_INTERRUPT_PRIORITY << (8 - configPRIO_BITS) )

/* !!!! configMAX_SYSCALL_INTERRUPT_PRIORITY must not be set to zero !!!!
See http://www.FreeRTOS.org/RTOS-Cortex-M3-M4.html. */
#define configMAX_SYSCALL_INTERRUPT_PRIORITY   ( configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY << (8 - configPRIO_BITS) )

/* Normal assert() semantics without relying on the provision of an assert.h
header file. */
/* USER CODE BEGIN 1 */   
#define configASSERT( x ) if( ( x ) == 0 ) { taskDISABLE_INTERRUPTS(); for( ;; ); }
/* USER CODE END 1 */

/* Definitions that map the FreeRTOS port interrupt handlers to their CMSIS
standard names. */
#define vPortSVCHandler    SVC_Handler
#define xPortPendSVHandler PendSV_Handler

/* IMPORTANT: This define MUST be commented when used with STM32Cube firmware, 
              to prevent overwriting SysTick_Handler defined within STM32Cube HAL */
//#define xPortSysTickHandler SysTick_Handler

#endif /* FREERTOS_CONFIG_H */

STM32F4 Timer Appears to Break RTOS Scheduler & Task

Well I’m afraid I cannot see anything wrong. The tick/systick handler should not not have any problems with the timer interrupt, and vice versa. Is the tick interrupt itself working (can you see xTickCount increment)? If not, then may something has left interrupt globally disabled. Regards.

STM32F4 Timer Appears to Break RTOS Scheduler & Task

Well…..I just don’t get it. My head is lumpy from hitting it on the wall. Why does calling this: MXTIM6Init(); Break FreeRTOS? so the scheduler won’t run. If I comment it out, no issues. Unbelievably frustrating that I am unable to find out why this is happening… aaaaarrrrgghhhhhh.

STM32F4 Timer Appears to Break RTOS Scheduler & Task

The init function…. /* TIM6 init function */ void MX_TIM6_Init(void) { TIM_MasterConfigTypeDef sMasterConfig; htim6.Instance = TIM6; htim6.Init.Prescaler = 0; htim6.Init.CounterMode = TIMCOUNTERMODEUP; htim6.Init.Period = 420000; HALTIMBase_Init(&htim6); sMasterConfig.MasterOutputTrigger = TIMTRGOENABLE; sMasterConfig.MasterSlaveMode = TIMMASTERSLAVEMODEDISABLE; HALTIMExMasterConfigSynchronization(&htim6, &sMasterConfig); }

STM32F4 Timer Appears to Break RTOS Scheduler & Task

MXTIM6Init() is just filling in a structure. HALTIMBaseInit() and HALTIMEx_MasterConfigSynchronization() are doing the work, but again looking at the definitions of those functions I cannot see anything that looks suspicious. Regards.

STM32F4 Timer Appears to Break RTOS Scheduler & Task

OK. So…which SysTickHandler can/could FreeRTOS use? IF I un-comment the one defined at the bottom of FreeRTOSConfig.h (xPortSysTickHandler), it breaks at the linker in port.c here:
  • Exception handlers. */ void xPortSysTickHandler( void );
/* * Start first task is a separate function so it can be tested in isolation. */ Error[Pe070]: incomplete type is not allowed C:UsersgrrDocumentsFreeRTOSV8.0.0FreeRTOSSourceportableIARARM_CM4Fport.c 151 (It’s the Kobeyashi Maru no-win scenario. And I’m not Captain Kirk…) Thanks, Gary

STM32F4 Timer Appears to Break RTOS Scheduler & Task

So…which SysTickHandler can/could FreeRTOS use?
I don’t know, I’m not familiar with the package. All I can do is speculate that if the comment says not to use the FreeRTOS one directly if you are using the Cube package then you shouldn’t uncomment the line. If it was a standard FreeRTOS demo then naturally you would use the FreeRTOS one. What is the SysTickHandler in your application doing? In the examples I just looked at all it seems to do is call HALIncTick(), which in turn just increments a variable, and toggle a pin. Regards.

STM32F4 Timer Appears to Break RTOS Scheduler & Task

Hi Try to verify your code pattern (initialization and tasks running + interruptions) usage/conventions from FreeRtos page. If you are using freertos system, then freertos encapsulates all exutable code/task management. Probably it is not recommended executing not managed code when freertos scheduler is active. 1.init system and pin configuration, execute some code not freertos managed 2.exit any running code, free resources 3.allocate freertos (task creation etc.) 4.run scheduler. 5.task is scheduled. and global communication is under freertos queues/generics !! any interuption can be activated with framework specific drivers in task code, but it`s necessary to verify implementation of priority settings and passed values. freertos has configLIBRARYMAXSYSCALLINTERRUPTPRIORITY and configMAXSYSCALLINTERRUPT_PRIORITY. configMAXSYSCALLINTERRUPTPRIORITY is shifted , but configLIBRARYMAXSYSCALLINTERRUPT_PRIORITY can be equivalent with platform specific, but it is not condition. So, any interuption that is activated under the freertos cannot have higher priority than configMAXSYSCALLINTERRUPT_PRIORITY. However, the interrupt subroutine(Timer ISR) communicates with freertos task, there have to be used ———FromISR(qHandle,w) freertos functions only. If the ISR subroutine has higher priority than MAXSYSCALLINTERRUPT_PRIORITY, the configASSRT() blocks the next code running in ———FromISR(qHandle,w) call.

STM32F4 Timer Appears to Break RTOS Scheduler & Task

Yes, I agree with what you are saying. However, this is not the cause of the problem. I have FeeRTOS v8 running on an LPC1768, and some of it is “unmanaged” – for example, I have an interrupt timer that runs quite nicely outside of FreeRTOS, but I do not do any calls to any FreeRTOS functionality while executing the ISR. If I needed to, I would follow what you are suggesting (And as does the folks at RTOS Engineering) On this STM32F4, all I am trying to do is have a peripheral timer count up, and execute a callback to read the ADC. Quite simple. Not on this device…first, figure out how to even get a timer configured…problem. Then, try to get it working with RTOS…problem…Looks like ST went out of their way to rush the HAL stuff out the door without figuring out if it really does work. What’s even funnier is that CUBE will generate all this nice code for you. You can put in RTOS, and timers, but that’s where the nice example falls short. There’s not actually any code that DOES anything, other than initialize. Once you try doing something, like set up a timer callback, the whole thing caves in. Nice going, ST! Looks like I have to bit bang with registers to solve the problem, something I really do not have the time for, but I’ve wasted enough time playing with their “solutions”. Thanks to anyone on this thread who took the time to help me with this…

STM32F4 Timer Appears to Break RTOS Scheduler & Task

Nothing in my application. I don’t even care about it. I’m trying to get the timer to work at sub-millisecond resolution for reading the ADC. What I find hilarious about that comment in the bottom of FreeRTOSConfig.h (about commenting out the define) is that, why did they even bother putting it there, if MUST be commented when using STM32Cube HAL firmware ?? Especially when their software creates this file? I guess they fell morally obligated to tell us HAL and FreeRTOS don’t play well together, and this is how they do it. Seems to be a bit of a smoke and mirrors act.

STM32F4 Timer Appears to Break RTOS Scheduler & Task

There are two cube packages. The first contains all the drivers and some projects to allow you to build examples and demonstrations. The second allows you to configure the pins on a chip and generate a software framework with the start up code and FreeRTOS, but not examples and demonstrations.

STM32F4 Timer Appears to Break RTOS Scheduler & Task

Hi, Thanks for the info – yes, I’m aware of that. Looks like I’ll have to abandon HAL (Software Odyssey 2014) and go with whatever canned ones they have pre-built and modify to suit.