Timer does not work

Kernel
1

eduardo1966 wrote on Tuesday, April 30, 2019:

Hi

I’m creating a timer like this:

    TimerHandle_t Timer;
    Timer = xTimerCreate ( "Timer_1second", TIME_SECONDS(1), pdTRUE, (void*)0, Callback_Timer );

The callback function creates a message that is sent to the task that created the timer:

static void Callback_Timer ( TimerHandle_t xTimer )
{
    IPreceiver_Message_t Timer_Message;

    Timer_Message.type = Timer_1second;

    if ( xQueueSend ( xQueue_Callback, (void*) &Timer_Message, 0 ) != pdPASS )
        /* In case there is no space in the Queue we wait for better days */
        ;
}

In the main task a switch case is used upon receiving the message:

        if ( xQueueReceive ( xQueue_Callback, &Callback_Message, portMAX_DELAY ) != pdTRUE )
            SP_Printf_h ( "ERROR - task_IPreceiver[] - xQueueReceive failed" );

        switch ( Callback_Message.type )
        {
            case Timer_1second:
            {

At the moment the case statement is never hit! However it was working before… I’ve been changing some options in FreeRTOSConfig.h but I believe I put everything back to as it was, but…

Any ideas about this?
Would there be any option in FreeRTOSConfig.h that some how makes the timer not work?
In fact this may be the one:

/* Software timer definitions. */
// <q> Enable timer
// <id> freertos_use_timers
#ifndef configUSE_TIMERS
#define configUSE_TIMERS 1
#endif

But it is 1.

thanks

2

eduardo1966 wrote on Tuesday, April 30, 2019:

It seems I have the same problem with vTaskDelay().
In the following code:

        pio_set ( LED1_PORT, LED1_PIN );
        vTaskDelay ( delay );
        pio_clear ( LED1_PORT, LED1_PIN );

The pio_clear() statement is never hit. The program crashes in the Fault_Handler().
This is something that I have changed because all this code was working… Ah, bugs… :slight_smile:

3

eduardo1966 wrote on Tuesday, April 30, 2019:

I just remember that I has to include the following lines in the linker file:

SECTIONS
{
    _itcm_lma = _end;
    .code_TCM :
    AT ( _itcm_lma )
    {
        _sitcm = .; *(.code_TCM); _eitcm = .;
    } > itcm

    .data_TCM :
    {
        _sdtcm = .; *(.data_TCM); _edtcm = .;
    } > dtcm

    .DTCM_stack :
    {
        . = ALIGN(8);
        _sdtcm_stack = .;
        . += STACK_SIZE;
        _edtcm_stack = .;
    } > dtcm
}

But now the linker gives some warnings:

Invoking: GNU ARM Cross C Linker
linker-script-flash.ld:199: warning: memory region `itcm' not declared
Finished building target: VDIU.elf
linker-script-flash.ld:204: warning: memory region `dtcm' not declared

I don’t remember why I had to declare the regions itcm and dtcm.

Could this be related with the problems I’m having?

4

eduardo1966 wrote on Tuesday, April 30, 2019:

The program crashes like shown in attachment

5

rtel wrote on Tuesday, April 30, 2019:

If if used to work but doesn’t now can you just diff between the older
working code and the newer code to see what changed, then post what the
changes are?

As a first comment it looks like the code

if ( xQueueSend ( xQueue_Callback, (void*) &Timer_Message, 0 ) != pdPASS )
        /* In case there is no space in the Queue we wait for better days */
        ;

is polling the queue to wait for space to become available, but it is
doing it from the timer callback. Callbacks execute in the context of
the timer task and it is common for the timer task to have the highest
priority in the system - if that is the case in your system then the
above code would effectively lock up the system because it is waiting
for another task to read from the queue while simultaneously preventing
any lower priority task from executing (because it has a higher priority
and is never in a state when lower priority tasks will be selected).

Next - in the screen shot - it looks like the hard fault was hit before
the scheduler was started even. If that is not the case then I suggest
using the code here:
https://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html
to figure out the location of the hard fault, then step through the code
in the debugger from there to see if you can catch the cause.