us_ticker_read() return a 0xFFFF less value for STM32F103RB.

[leibin2014]

I use the following code to simulate a 500us/2000us software PWM on PB_0 :

 #include "mbed.h"

DigitalOut out0(PB_0);

Timeout t;

extern void pin_off_callback();
void pin_on_callback()
{
    out0 = 1;
    t.attach_us(&pin_off_callback, 500);
}
void pin_off_callback()
{
    out0 = 0;
    t.attach_us(&pin_on_callback, 2000-500);
}

int main()
{
    out0 = 1;
    t.attach_us(&pin_off_callback, 500);
        while(1)
      {

      }
}

No problem is found when it run on STM32F100RB, but found a problem when run it on STM32F103RB. I found some 65ms continuous high(1) or low(0) level voltage on PB_0 each about 10 seconds.

After digging into thIS problem, I found this is due to in us_ticker.c of STM32F103RB it uses the same IRQ function for update and compare interrupts. So if us_ticker_read() is called in us_ticker_irq_handler(), and at the same time if a update interrupt happens, the variable SlaveCounter has no chance to increase 1. SlaveCounter will be just updated in the next calling of IRQ function. So the function us_ticker_read() will return a 0xFFFF less value in current IRQ function, then cause the 65ms blank area problem.

If running the previous code is easily to reproduce this problem on STM32F103RB. This problem can't be reproduced on STM32F100R since STM32F100RB uses different IRQ fucntions for update and compare interrupts with different priorities.

I know the cause, but don't have good idea about how to fix it. Could any one help to have a check and help to fix it?

[bcostm]

This issue is related to the 16-bit timer used for the Ticker.
It is also present on STM32F0xx, STM32F1xx and STM32L0xx targets. Other targets using a 32-bit timer has not this problem (STM32F3xx, STM32F4xx, STM32L1xx).
No satisfying solution found yet.

[JojoS62]

I see the same problem. The 65 ms burst looks like a 16 bit overflow: it is something like 65535 microseconds. Then after this burst, the new timestanps are calculated. As they are in the past, the INT is called immediately. This results in calls with high frequency until the missing calls are worked up and the normal cycle is running. Until the next overflow.
Screenshots show Ticker with 5 kHz toggling a portPin.

[0xc0170]

@bcostm What's the status?

[bcostm]

Same as in June 2015. No solution found on this problem.

[JojoS62]

I think leibin2014 found already the reason. The problem is that a 32 bit counter is needed and the implementation to extend the 16 bit counter is wrong. The 16 bit overflow is not handled correctly, it does not increment the high word of the counter. My suggestion:

in: https://github.com/mbedmicro/mbed/blob/master/libraries/mbed/targets/hal/TARGET_STM/TARGET_STM32F1/us_ticker.c

// remove oc_int_part, oc_rem_part declararations

volatile uint32_t SlaveCounter = 0;
volatile uint16_t counterOld = 0;

uint32_t us_ticker_read()
{
    uint16_t counter;
    if (!us_ticker_inited) us_ticker_init();

    counter  = TIM_MST->CNT;
    if (counter < counterOld) {
        SlaveCounter += 0x10000;    // timer overflow, increment high word 
    }

    SlaveCounter += (SlaveCounter & 0xFFFF) + counter;
    counterOld = counter;

    return SlaveCounter;
}

I don't have the ARM/Keil toolchain for testing, maybe someone else can try this?

[bcostm]

ok thanks. I have Keil and IAR. I will check this.

[JojoS62]

I'm trying also with gcc-arm. And I see already that us_ticker_set_interrupt() needs to be modifyed also.

[JojoS62]

sorry, that is too complicated for me at the moment. There is also a dependency on hal_tick.c, function timer_irq_handler(). This tries to handle time spans >65536 µs.