• AVR Freaks

Hot!dspic33ep64mc504 32bit timer timer2:timer3

Author
seyyah
Super Member
  • Total Posts : 609
  • Reward points : 0
  • Joined: 2004/05/14 12:49:28
  • Status: offline
2019/04/25 02:58:43 (permalink)
0

dspic33ep64mc504 32bit timer timer2:timer3

I think there is a problem with this timer. I'm using timer2/3 in 32 bit mode @70MHz. When I read it I use this code:
 
countValLower = TMR2; // read lsw first
countValUpper = TMR3HLD; // then read msw
countVal = (((uint32_t)countValUpper << 16) | countValLower);

 
but every once in a while countValUpper(TMR3HLD) is not loaded correctly. I noticed that it is partly loaded and I tried to add a Nop() before I read it, I read TMR2 and TMR3HLD double times but the problem did not exactly disappear. I also used a second set of variables and read them after a few cycles later:
 
countValLower2 = TMR2; // read lsw first
countValUpper2 = TMR3HLD; // then read msw
countVal2 = (((uint32_t)countValUpper2 << 16) | countValLower2);

 
 
Sometimes set one is true, some times set two is true and sometimes both are the same (only a few cycles difference).
 
I think this is a problem that does not meet specifications and must be added to errata. Am I wrong?
 
I also noticed a similar problem when I use ic1/ic2 in conjunction to form a 32 bit input capture. If I read them when the lsw is at the end and while the msw is being updated.
 
So anyone knows about it, the problem? The solution? Thanks.
#1

7 Replies Related Threads

    du00000001
    Just Some Member
    • Total Posts : 2624
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: offline
    Re: dspic33ep64mc504 32bit timer timer2:timer3 2019/04/25 04:03:48 (permalink)
    0
    Did you keep in mind that - provided the timer is constantly counting - there might be a rollover/carry to TMR3 ?
    In which case it might be that TMR3 is within the process of incrementing when you access TMR2 and thus latch the recent value of TMR3 ?
    In which case TMR3 would be 1 increment too low.
     
    Whether this happens, has to do with the exact moment you access TMR2. Thus you should be able to derive whether this happened from the value read from TMR2: values > 0xFFFD and values < 0x0003 might be somewhat "suspect", while I expect that your other readings should be fine.

    Would these considerations mitigate your issue?

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #2
    Howard Long
    Super Member
    • Total Posts : 663
    • Reward points : 0
    • Joined: 2005/04/04 08:50:32
    • Status: online
    Re: dspic33ep64mc504 32bit timer timer2:timer3 2019/04/25 06:10:10 (permalink)
    0
    Can you please present a complete code example that demonstrates your problem?
    #3
    Howard Long
    Super Member
    • Total Posts : 663
    • Reward points : 0
    • Joined: 2005/04/04 08:50:32
    • Status: online
    Re: dspic33ep64mc504 32bit timer timer2:timer3 2019/04/25 06:20:06 (permalink)
    0
    du00000001
    Did you keep in mind that - provided the timer is constantly counting - there might be a rollover/carry to TMR3 ?
     



    Perhaps I've misunderstood, I think that's the point of reading the low TMR2 word first which automatically latches the TMR3HLD SFR?
     
    http://ww1.microchip.com/downloads/en/DeviceDoc/S11.pdf page 11-17.
    #4
    seyyah
    Super Member
    • Total Posts : 609
    • Reward points : 0
    • Joined: 2004/05/14 12:49:28
    • Status: offline
    Re: dspic33ep64mc504 32bit timer timer2:timer3 2019/04/25 06:38:15 (permalink)
    0
    du00000001
    Did you keep in mind that - provided the timer is constantly counting - there might be a rollover/carry to TMR3 ?
    In which case it might be that TMR3 is within the process of incrementing when you access TMR2 and thus latch the recent value of TMR3 ?
    In which case TMR3 would be 1 increment too low.
     
    Whether this happens, has to do with the exact moment you access TMR2. Thus you should be able to derive whether this happened from the value read from TMR2: values > 0xFFFD and values < 0x0003 might be somewhat "suspect", while I expect that your other readings should be fine.

    Would these considerations mitigate your issue?


    That kind of thing is happening when I use ic1/ic3, i detect it and correct it and only single bit is the problem....
    In timer case the last 3 msbits or 2msbits or the msb of timer3 is zero, or not loaded or masked some how.
     
    #5
    seyyah
    Super Member
    • Total Posts : 609
    • Reward points : 0
    • Joined: 2004/05/14 12:49:28
    • Status: offline
    Re: dspic33ep64mc504 32bit timer timer2:timer3 2019/04/25 07:08:34 (permalink)
    0
    Howard Long
    Can you please present a complete code example that demonstrates your problem?




    Actually my mind is very tired now and I've tried a lot of things. I'm exhausted.
     
    Actually the problem is easy. I'm trying to measure the speed of a small motor using an incremental encoder which I've done many times before. In this case I only use A channel to measure the speed, A and B channel to measure the position. Using QEI, position measurement is not a problem. And there should be no problem with the speed measurement but I'd have many adventures, it is a long story, nevermind. 
     
    I've remapped home input same as the A signal to measure the period of the A pulse since QEI module has no interrupt for QEA and QEB signals, and I decided to use HOME signal for this purpose (I've also tried INDX with the same result). To measure the time, I used timer2:timer3 (Don't ask why I'm not using interval timer, velocity feature, input capture etc,  As I've said it is a long story). At every interrupt I clear the timer, and at the other interrupt I capture the timer value. Precision is enough for me.
     
    The idea works but occasionaly I get wrong values. 1 or 2 in a 500 reads. The pulse period is constant and ~670µs.
     
    I first suspected that the module does not generate the interrupt correctly sometimes but then I created 2 arrays to keep the captured values to be sure it is not a timer problem. And the test resulted as I've described in my first post.
     
    Then I compared the position values at every interrrupt. The position value difference must be the same everytime and saw that when I get wrong values also the difference value differs. Which shows that the interrupt is generated at the wrong time.
     
    I could not related two, I'm confused, I'm tired and I simply ignore values as a solution when the position difference value is not what expected for now.
     
    Thank you very much.
     
    void __attribute__ ( ( interrupt, no_auto_psv ) ) _ISR _QEI1Interrupt( void )
    {
        uint32_t countVal = 0xFFFFFFFF;
        uint16_t countValUpper = 0;
        uint16_t countValLower = 0;

        uint32_t countVal2 = 0xFFFFFFFF;
        uint16_t countValUpper2 = 0;
        uint16_t countValLower2 = 0;
       
        if(QEI1STATbits.HOMIRQ == 1)
        {
            // read
            countValLower = TMR2;
            countValUpper = TMR3HLD;
            countVal = (((uint32_t)countValUpper << 16) | countValLower);
            
            // calculate speed
            speed = 70000000ul / countVal;
            
            // read 2nd time
            countValLower2 = TMR2;
            countValUpper2 = TMR3HLD;
            countVal2 = (((uint32_t)countValUpper2 << 16) | countValLower2);

           capArray[indx] = countVal ;
           capArray2[indx] = countVal2 ;

            if(++indx > 499)
                 indx = 0;
        }

        IFS3bits.QEI1IF = 0;

    }

     
     
    #6
    seyyah
    Super Member
    • Total Posts : 609
    • Reward points : 0
    • Joined: 2004/05/14 12:49:28
    • Status: offline
    Re: dspic33ep64mc504 32bit timer timer2:timer3 2019/04/25 07:34:38 (permalink)
    0
    Oh I noticed that it has nothing to do with Timer3 because the value doe not exceed 16 bit value. So I am actually only reading timer2. So I may be be confusing things after restless hours, sorry.
    #7
    du00000001
    Just Some Member
    • Total Posts : 2624
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: offline
    Re: dspic33ep64mc504 32bit timer timer2:timer3 2019/04/25 07:35:28 (permalink)
    0
    @ seyyah
    Could it be another interrupt interferes?
    Your "measurement" is obviously based on the hope that execution time (delay) is constant. Which might or might not apply.

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #8
    Jump to:
    © 2019 APG vNext Commercial Version 4.5