Proton BASIC Community

Hi,
This is a 4-character 7 segment display unit driven from 18F24K22.The display is constructed out of 4 nos. 4094 shift registers connected in cascade & driven through the STROBE/DATA/CLOCK lines. The lines are LATB.7/LATB.6/LATB.5. The display is supposed to receive the weight data through the Rx pin , display it for 30 seconds & then blank out.Only the units place decimal point keeps on blinking so that the observer knows that the display is alive & waiting for the next data to arrive. I am enclosing the commented code.

The problem is an irritant which I am unable to pinpoint.Whenever the serial data(4 byte SDWORD) is received , the display shows the data for 30 seconds...no problem there.After the 30 seconds is elapsed the display freezes in the blank state for about 5 seconds when the units decimal point also stops blinking. After this latch-up period the DP starts blinking once again & the display goes back to normal state & displays the next received data.
What is causing this freezing/latch-up?
Thanks in advance.

Hi,
Just a thought, does it happen if you disable the watchdog??

Regards,
Bob

Quote from: shantanu@india on Dec 03, 2021, 02:22 PMthe display freezes in the blank state for about 5 seconds when the units decimal point also stops blinking

This suspiciously looks like the 5 sec delay you give after power-up, check if the device doesn't reset?

Thanks Bob and Trastikata.
Yes... I was thinking along the same lines and first thing I did was to disable the Watchdog.
The same latch up occurred which vanished automatically!!
So apparently the device is not resetting

Quote from: shantanu@india on Dec 03, 2021, 04:56 PMSo apparently the device is not resetting

I was thinking it could be resetting for another reason. Change the delay after power-up from 5 to 10 seconds and see if the latch period is changing too.

If this is the case - the only other reason I can think of for resetting, is BOR after you send 255 and power on all LED segments, there might be a current spike and voltage drop that the regulator can't handle, hence the BOR.

In your display driver are you multiplexing the segments? Eg only ever displaying 1 x 7 seg display at a time.

Tim

I have simulated your program in proteus and it does not produce any error, to know if it is restarting you send the ultratech text, if it appears more than once it would be restarting, cancel the detection of the bor in the fuse configuration BOREN = OFF if that is the case.You can also turn on a led before the cycle to know if it restarts

BOR... I haven't thought of that!!
I'll try and report back.
Thanks.

Quote from: TimB on Dec 03, 2021, 07:39 PMIn your display driver are you multiplexing the segments? Eg only ever displaying 1 x 7 seg display at a time.

Tim

No Tim... no multiplexing. Loading all the segments and then updating by strobing the 4094's

Where do you clear PIR1.5, the USART interrupt? It should be in your interrupt routine, below:

Context Save
        If PIR1.5=1 Then
          inbyte=RCREG1
                                                                    '# & % are the wrapper characters around the 4byte data...total 6 bytes   
              If inbyte="#" And rx_start=0 Then                               
                buff_ptr=0
                rx_start=1               
              ElseIf inbyte="%" And rx_start=1 And buff_ptr=4 Then 
                rx_start=0               
                buff_ptr=0
                rx_stop=1                 
              ElseIf rx_start=1 And buff_ptr<4 Then
                inbuffer[buff_ptr]=inbyte
                Inc buff_ptr                         
              EndIf
             
        ElseIf PIR1.0=1 Then          '@100 msec
            Clear PIR1.0
            timer=15535
            Inc timercount1
             
            If timercount1=5 Then
                timercount1=0
                disp_flag=1
                Toggle heartbeat               
            EndIf                   
           
                   
        EndIf     

  Context Restore

Quote from: shantanu@india on Dec 04, 2021, 05:56 AMNo Tim... no multiplexing. Loading all the segments and then updating by strobing the 4094's

OK I double checked the code and see you are using a seperate Led driver not directly of the pic

Quote from: charliecoutas on Dec 04, 2021, 10:06 AMWhere do you clear PIR1.5, the USART interrupt? It should be in your interrupt routine, below:

Charlie, PIR1.5 (RC1IF) is automatically cleared after RCREG1 has been read.

I also have the habit to clear the RC1IF in the code, but it is actually not needed.

Well I learn something every day! Thanks.

Just to note - as mentioned, in the 8-bit parts RCxIF is read-only and clears when you read RCREGx.

The 16-bit parts don't work this way... you have to clear the IFSxx bit manually.
 

This is the simulation

Thanks for taking the pains to simulate Pepe... I really appreciate it!

Giving what I receive is always good

Today ultimately I was able to pinpoint the source of error.. nothing to do with the code at all!!
Pulling down the strobe/data/clock lines with 10K resistors and connecting a 100uF filter capacitor across the supply rails solved the problem.