TIM5 problem with STM32F469I

[Jerry Hancock]

I am using 32bit TIM5 in an STM32F469I. I enable the timer and divide the 8M clock by 1000000 to get microseconds. I then use microseconds to time pulses coming into the board from external device. All works well until the timer overloads. I can test this as I save the current and previous timer counts. When the current is less than the previous in count, I know it overloaded.

I thought that TIM5, a 32 bit timer, should reload on overflow. Once it overloads, it seems to go into a 16bit mode, I don't know, but the counts are lower than expected. They look like miliseconds at most instead of microseconds. Since all this is in an interrupt it is hard to tell.

Here's how I set the timer up. And by the way, all is well for about a minute, which would coincide roughly with the overflow as well. Ignore any subtle spelling errors as I had to type this in instead of copy/paste

__HAL_RCC_TIM5_CLK_DISABLE(); // tried with and without this statement

__HAL_RCC_TIM5_CLK_ENABLE();

TIM5->PSC=HAL_RCC_GetPCLK1Freq() / 1000000-1; // Clock should return 8,000,000

TIM5->CR1=TIM_CR1_CEN | TIM_CR1 | TIM_CR1_ARPE; // Tried with/without TIM_CR1_ARPE as it shouldn't be needed

I then read the timer with:

mctime = TIM5->CNT;

mctime counts up to a large 32bit number and then overflows and after that, slowly counts. At overflow I tried disabling the timer and re-enabling it. Maybe something else is using TIm5 on the board but I can't find it.

Pointers?

Thanks,

Jerry

[Tesla DeLorean]

TIM5->ARR is set to what?

This stuff is hard to remotely troubleshoot with incomplete code, no code showing diagnostic output, and no output to review.

[Jerry Hancock]

ARR is set to 0xffffffff;

At initialization, the only difference I can see between then and at overflow is that init has SR=0x00 and at overflow SR = 0x1f;

CR1 is 0x81;

CNT is random depending on when it stops;

PSC = 0x29;

DMAR = 0x81;

Everything else is 0x00;

Do I need to clear the Status Register SR at overflow?

Thanks for trying.

Jerry

[Jerry Hancock]

Is there something I should be doing in the interrupt at overflow? I've been debugging this all afternoon without luck.

thanks

[Tesla DeLorean]

>>Do I need to clear the Status Register SR at overflow?

Are you interrupting?

If you want to see each Update event flagged, you'd want to clear the first one, ie TIM5->SR = 0xFFFE;

Don't have an F469I that's not in use

Here TIM5 cycling on an F7, rolls every 43, doesn't filp into 16-bit mode

Hello World!
Prescaler 0
    0 :          3
    1 :  100090821
    2 :  200190821
    3 :  300290819
    4 :  400390819
    5 :  500490821
    6 :  600590821
    7 :  700690821
    8 :  800790821
    9 :  900890821
   10 : 1000990821
   11 : 1101090821
   12 : 1201190821
   13 : 1301290821
   14 : 1401390819
   15 : 1501490819
   16 : 1601590821
   17 : 1701690821
   18 : 1801790821
   19 : 1901890821
   20 : 2001990821
   21 : 2102090821
   22 : 2202190819
   23 : 2302290821
   24 : 2402390821
   25 : 2502490821
   26 : 2602590821
   27 : 2702690821
   28 : 2802790821
   29 : 2902890821
   30 : 3002990821
   31 : 3103090821
   32 : 3203190821
   33 : 3303290821
   34 : 3403390819
   35 : 3503490821
   36 : 3603590819
   37 : 3703690819
   38 : 3803790819
   39 : 3903890821
   40 : 4003990821
   41 : 4104090819
   42 : 4204190821
   43 :    9323525
   44 :  109423525
   45 :  209523525
   46 :  309623523
   47 :  409723525
   48 :  509823525
   49 :  609923525
   50 :  710023523
   51 :  810123525
   52 :  910223525
   53 : 1010323525
   54 : 1110423525
   55 : 1210523525
   56 : 1310623523
   57 : 1410723525
   58 : 1510823525
   59 : 1610923525
   60 : 1711023523
   61 : 1811123525
   62 : 1911223525
   63 : 2011323525
   64 : 2111423523
   65 : 2211523525
   66 : 2311623525
   67 : 2411723523
   68 : 2511823525
   69 : 2611923523
   70 : 2712023525
   71 : 2812123525
   72 : 2912223525
   73 : 3012323525
   74 : 3112423525
   75 : 3212523525
   76 : 3312623525
   77 : 3412723525
   78 : 3512823525
   79 : 3612923523
   80 : 3713023525
   81 : 3813123525
   82 : 3913223525
   83 : 4013323525
   84 : 4113423525
   85 : 4213523525
   86 :   18656229
   87 :  118756229
   88 :  218856229
   89 :  318956229
   90 :  419056229
   91 :  519156229
   92 :  619256229
   93 :  719356229
   94 :  819456229
   95 :  919556229
   96 : 1019656229
   97 : 1119756227
   98 : 1219856227
   99 : 1319956229
  100 : 1420056229
  101 : 1520156229
  102 : 1620256227
  103 : 1720356227
  104 : 1820456229
  105 : 1920556229
  106 : 2020656227
  107 : 2120756229
  108 : 2220856229
  109 : 2320956227
  110 : 2421056227
  111 : 2521156229
  112 : 2621256229
  113 : 2721356229
  114 : 2821456229
  115 : 2921556229
  116 : 3021656229
  117 : 3121756229
  118 : 3221856227
  119 : 3321956229
  120 : 3422056229
  121 : 3522156227
  122 : 3622256229
  123 : 3722356229
  124 : 3822456229
  125 : 3922556229
  126 : 4022656229
  127 : 4122756229
  128 : 4222856227
  129 :   27988933
  130 :  128088933
  131 :  228188931
  132 :  328288933
  133 :  428388933
  134 :  528488933
  135 :  628588933
  136 :  728688933
  137 :  828788933
  138 :  928888933
  139 : 1028988933
  140 : 1129088933
  141 : 1229188933
  142 : 1329288933
  143 : 1429388933
  144 : 1529488931
  145 : 1629588933
  146 : 1729688933
  147 : 1829788933
  148 : 1929888933
  149 : 2029988933
  150 : 2130088933

[Jerry Hancock]

all I need is the continuous count. I need a more granular time than what is given in ticks. I don't care if they are microseconds between incoming pulses. Before the timer overflow, all is well. Once it overflows, the count between pulses is about 1/4 or less what they should be even though PSC is the same. Consequently, the routine that looks at the timing thinks all pulses are fast after the overflow opposed to a scale of from 1 to 4 and all above 4 are treated the same way.

I'm looking at the RCC clock speed right now as I can't figure out why I am seeing 40 in the PSC register. I would have thought it should be 8 as I thought the RCC was running at 8Mhz.

But it no matter the accuracy of the count, it should be consistent and it isnt. After the overflow it is about 1/4th as fast.

What is the PSC in your TIM5?

Thanks

[Jerry Hancock]

there is something hosed up that I don't understand. If I grab the TIM5 count, use HAL_Delay(10) for a 10ms delay, then grab the count again and subtract, no matter what I have in the PSC register I get the same approximate delta count of 789,354. It should be around 10,000. So I have something else wrong here that I don't understand. I mean, the setup code for TIM5 is pretty basic. I tried moving the PSC register from 39 to 7 and back to 3,200 with no change in the delta count.

I have to think about this now as it isn't working as expected. The overflow isn't set

[Jerry Hancock]

well, I don't know why but adding below changed things and now it is working:

__HAL_RCC_TIM5_CLK_ENABLE();

TIM5->PSC=HAL_RCC_GetPCLK1Freq()/1000000-1;

TIM5->CR1=TIM_CR1_CEN | TIM_CR1_DIR;

I added TIM_CR1_DIR just as a test and for some reasons the TIM5 is now reporting closer to a microsecond. Before when I delayed like this:

mltime=TIM5->CNT;

HAL_Delay(10);

mctime=TIM5->CNT;

mstime=mltime-mctime;

mstime was being set to 798,000 give or take a few percent. Now it is down around 20,000 with the expectation that it would be around 10,000 for 10,000 microseconds.

I thought that TIM_CR1_DIR just set the countup or countdown direction but other than the direction something else must have changed. I had already changed the code to account for roll-over and I didn't change that code.

Anyway, unless someone can explain the reason why this is working I will just move on.

Thanks again Clive.

Jerry

[waclawek.jan]

The counter is upcounting unless CR1.DIR is set, so you should've calculated mstime = mctime - mltime.

JW