Framing error if I disable transmitter after shift register is empty?

[amgen]

don't give up on yourself or sell yourself short !...... it is a good project

[Demon]

don't give up on yourself or sell yourself short !...... it is a good project

It's an awesome project. I can almost see the light at the end of the tunnel. I've done unit tests of every component all the way up to interfacing with MS Flight Sim. I'm just not seeing why I can't disable the transmitter in PIC #1.

I added a PAUSE to guarantee that everything is sent on PIC #1. The 2 PICs transmit successfully back and forth, and then I get a lone FRAMING ERROR all by itself, and PIC #2 locks up (there are no more blinking LED on channel 3).

    TXSTA.5 = 1                     ' TXEN: Transmit Enable bit
    hserout [   "[1]"    ]                             
    while TXSTA.1 = 0               ' Check TRMT: Transmit Shift Register Status bit
    wend
    
    PAUSE 100
    
    TXSTA.5 = 0                     ' <----- Causes Framing error after last byte !

So it's not an issue of losing bytes, it's definitely something peculiar about TXSTA.5 = 0.

[tumbleweed]

DISABLE transmitter causes a FRAMING ERROR on 1st PIC, but not on Ack message on 2nd PIC

In post 8 the trace is showing that the analyzer is detecting a framing error being generated by the transmitter when it sends the ']' and disables TXEN.
The TX data line should never idle low... that looks like a serial BREAK condition to the receiving side and will likely generate framing and overrun errors on that end.

A framing error by itself doesn't really cause any issues, but an overrun error will stop everything in its tracks until you clear the error. I see you have 'DEFINE HSER_CLROERR 1', so hopefully that's trying to take care of it, but maybe not. The way you have the receive arranged if things get out of sync then it might lock up waiting for something that's not going to happen.

As I said, if setting TXEN=0 causes the TX data line to go low that you need to change the TRIS/LAT register settings in your setup to stop that from happening.
Try initializing the pins with LATC6 = 1 and TRISC6 = 1. That should set the default state of the TX pin to high, which is the proper idle state.

You'll have to rethink all of this later when you try to add more devices since you can't just tie multiple TX outputs together, even if they're "disabled".
They would need to be tri-state/open-drain in the idle state, not driven high or low.

[Demon]

...You'll have to rethink all of this later when you try to add more devices since you can't just tie multiple TX outputs together, even if they're "disabled".
They would need to be tri-state/open-drain in the idle state, not driven high or low.

Yes, they'll definitely be tri-state.

[Demon]

PIC #1:

    TXSTA.5 = 1                     ' TXEN: Transmit Enable bit
    hserout [   "[1]"    ]                             
    while TXSTA.1 = 0               ' Check TRMT: Transmit Shift Register Status bit
    wend
    hserin [ wait("["), STR RecvData\11\"]" ]
    hserout [   "[2]"    ]                             
    while TXSTA.1 = 0               ' Check TRMT: Transmit Shift Register Status bit
    wend
    pauseus 300
    TXSTA.5 = 0                     ' <----- Causes Framing error after last byte !

Mainloop:
    BlinkLED = 1
    BlinkLED = 0
    goto mainloop
end

PIC #2:

ReceiveInterrupt:
    hserin [ wait("["), STR RecvData\11\"]" ]
    UsartFlag = 1
@ INT_RETURN

Start:
    Pause 200                           ' Let PIC and LCD stabilize

Mainloop:
    LEDblink = 1
    if UsartFlag = 1 then
        TXSTA.5 = 1
        hserout [   "[0]"  ]                            
        while TXSTA.1 = 0              ' Check TRMT bit
        wend
        UsartFlag = 0
        TXSTA.5 = 0
    endif
    LEDblink = 0
    GOTO Mainloop
end

1. PICs can talk back and forth with no errors.

2. PIC #2 can disable transmitter every single time.

3. Framing error as soon as PIC #1 disables transmitter, causing PIC #2 to lock up (no more blink LED on bottom channel).

[Demon]

IT'S THE DARN PIC !

I swapped the coding between the 2 PICs, and PIC #1 now has a framing error every time it tries to disable the transmitter.




I'm going to swap it for another unit and see if that changes things.

[richard]

when you disable the transmitter how are you setting the tx pin
code ?

[Demon]

Hmmm, I moved PIC #2 up in PIC #1 spot, and put in a new unit in PIC #2 spot.

PIC#1 can now disable transmitter at will, YAY! So that confirms that there's nothing on the breadboard interfering with that PIC.

New PIC #2 gets a framing error, but neither of the PICs freeze now (I put the blinky channel right under each PIC).




PIC#1:

Start:
    TXSTA.5 = 1                     ' TXEN: Transmit Enable bit
    hserout [   "[1]"    ]                             
    while TXSTA.1 = 0               ' Check TRMT: Transmit Shift Register Status bit
    wend
    TXSTA.5 = 0                     ' <----- Causes Framing error after last byte !

    hserin [ wait("["), STR RecvData\11\"]" ]

    TXSTA.5 = 1                     ' TXEN: Transmit Enable bit
    hserout [   "[2]"    ]                             
    while TXSTA.1 = 0               ' Check TRMT: Transmit Shift Register Status bit
    wend
    TXSTA.5 = 0                     ' <----- Causes Framing error after last byte !

Mainloop:
    BlinkLED = 1
    BlinkLED = 0
    GOTO Mainloop
end

PIC #2:

@   INT_ENABLE   RX_INT
    goto Start

ReceiveInterrupt:
    hserin [ wait("["), STR RecvData\11\"]" ]
    UsartFlag = 1
@ INT_RETURN

Start:

Mainloop:
    LEDblink = 1
    if UsartFlag = 1 then
        TXSTA.5 = 1
        hserout [   "[0]"  ]                            
        while TXSTA.1 = 0              ' Check TRMT bit
        wend
        UsartFlag = 0
        TXSTA.5 = 0
    endif
    LEDblink = 0
    GOTO Mainloop
end

Might have a few ideas more ideas to try out...

[Demon]

I decreased the pause to 300uSec so everything is in the window when zoomed in.

The 2 transmits are working just fine, with the framing error over on the right.