System Clock issue... I think

CannibalRobotics

Hi all,
I am using this loop to hold for a precision pulse delay. It works great for awhile then the loop just·hangs for several minutes then starts back up again working beautifully. It runs for a while then hangs again consistantly repeating this process. I'm·pretty sure·that I'm hitting the zero cross-over on the system clock (cnt) and it's not a·hang but a very long delay increment has been inserted into t2. The t2 counts run·between 72_000 to 152_000. Since the loop does not depend on anything else and the other two calls are rock solid I'm thinking this is the solution.
Any clever ways to avoid this or should I just increment a register based counter that always starts at 0?
Thanks
Jim-

                        MOV     Chan,#0                 ' Set Chan to #0    
                                                        ' End of Loop setup
                                                        
MainLoop                MOV     t1,buff                 ' Put Incomming data buffer address on t1
                        ADD     t1,Chan                 ' Offset buffer Address by channel
                        rdlong  t2,t1                   ' Read value in address t1 into register t2
                        ADD     t2,CNT                  ' Add system count to t2
                        CALL    #SetBit                 ' Turn the pulse on at Chan (16 clock cycles)
                        Call    #SendData               ' Put it out on the latch (4.7uSec)
:MainLoopDelay          CMP     t2,cnt          wc      ' compare t2 to system clock set carry if t2 < CNT
              if_nc     jmp     #:MainLoopDelay         ' if c is not set, have not counted high enough, go round again

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Signature space for rent!
Send $1 to CannibalRobotics.com.

Timmoore

This doesn't handle when cnt wraps

                        mov     t1,rxcnt3             'check if bit receive period done
                        sub     t1,cnt
                        cmps    t1,#0           wc
        if_nc           jmp     #:wait3

This is the code used in the serial port for bit timing. The sub and cmp doesn't handle the wrap.

CannibalRobotics

How is the value for rxcnt3 calculated? period + cnt?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Signature space for rent!
Send $1 to CannibalRobotics.com.

Mike Green

If the system clock wraps around between the "ADD t2,CNT" and the "CMP", your comparison won't work the way you want. I also recommend that you use WAITCNT for precision delays. One question is whether the time delay can be zero or "less than zero". In other words, is there always at least a short delay after the call to "SendData"?

Here's one implementation. "minDelay" has to be the maximum number of system clock cycles needed for everything from the "add t2,cnt" to the "waitcnt" plus a little extra. It provides a "floor" for the time delay. You could leave out the "min t2,#minDelay" if you're certain that the incoming data will never have a delay shorter than the minimum allowed.

MainLoop            mov      t1,buff
                         add       t1,Chan
                         rdlong   t2,t1
                         min       t2,#minDelay
                         add       t2,cnt
                         call       #SetBit
                         call       #SendData
                         waitcnt  t2,#0

CannibalRobotics

SendData and SetBit are completely predictable in timing - ie. no cog dependant instructions and the loops are set in terms of numbers of cycle's.
What I'm hearing is that if I set #mindelay to a number just greater than the total cycle time of #SetBit and #SendData this should work without the wrapping issue?

Jim-

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Signature space for rent!
Send $1 to CannibalRobotics.com.

Mike Green

Yes. Set minDelay to the worst case number of clock cycles needed for SetBit and SendData including the calls and returns plus 1-2 cycles for the add (after the access to cnt) plus 5-6 cycles for the waitcnt plus a couple of cycles just to play it safe in case of errors (in counting clock cycles in the code).

CannibalRobotics

This worked but MinDelay was necessary. Operationally, the counts are much larger than that cycle time but at start-up the buffer is full of zeros waiting on other cogs to start up then populate the buffer.
Rather than pre-stuff the buffer I decided the safety margin of 'min' was nice. Just in case some other routine jammed a zero in at some inoppertune moment.

Thanks Mike!

Jim-

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Signature space for rent!
Send $1 to CannibalRobotics.com.

Mike Green

This is the sort of information you could have provided in your initial message. Of course, if you'd thought of it, you might have solved your problem yourself.

I've mentioned before that weird problems with code are often due to problems with initial conditions or assumptions that you've made that that are false. It's a learnable skill to be able to back off and look at your own code as if you were someone else new coming to look at it. It's very useful.