UART 3 Will Not Accept 5th Byte

Question

The chip in question is PIC24FJ256GB210

It is a 100-Pin TQFP form factor

We have an embedded system with two microprocessors.

The two microprocessors use a UART to communicate Which is (according to me) mapped to UART #3 on the PIC24.

I place 4 bytes into UART #3. All goes well. The 5th byte will not go in.

I say FIFO backup.

My local hardware expert says that if I turn off flow control that the bytes will go out no matter what.

Is this true ? I've never heard that one before. I thought it was a hardware signal on the other side; i.e., a read signal has to occur on the other side before the FIFO buffer would allow room on this side.

His definition of "turn off flow control" is for me to not use PPS (Peripheral Pin Select) to map either the RTS (Request to Send) or CTS (Clear To Send) pins to their corresponding physical pin on the board.

I did that. Result: no change; the FIFO buffer still fills up. The "#UTXBF" bit never clears after the fourth byte goes in.

I have the schematic diagram with physical pins numbered and labeled.

I have the source code and MpLab showing the executable down at the register level, right at the assembly language instructions themselves.

I am mapping the pins of UART #3 exactly and identically to the manner that I am mapping UART #2 and UART #1, and both of those other two work perfectly.

While the numbers are different, the instruction sequences are identical. The numbers match the pins.

I am debugging this for the third time, watching each bit in each register and comparing them against the manual to make sure that I have the correct corresponding numbers in the correct bit positions in the correct special function registers.

This is from MpLab's disassembler window where the opcodes show exactly which bits are set and cleared.

 206CC1     mov.w #0x6cc,0x0002            Mov     #Uart_3_Tx_PPS_Output_Register, W1              ;This is the register we want
 21C002     mov.w #0x1c00,0x0004           Mov     #Uart_3_Tx_Or_In_Bit_Pattern, W2                ;These are the bits we want on
 2C0FF3     mov.w #0xc0ff,0x0006           Mov     #Uart_3_Tx_And_Off_Bit_Pattern, W3              ;These are the bits we want off

 780211     mov.w [0x0002],0x0008          Mov     [W1], W4                                        ;The existing pattern
 618204     and.w 0x0006,0x0008,0x0008     And     W3, W4, W4                                      ;Turn existing bits off
 710204     ior.w 0x0004,0x0008,0x0008     Ior     W2, W4, W4                                      ;Turn Desired bits on
 780884     mov.w 0x0008,[0x0002]          Mov     W4, [W1]                                        ;And that's all there is to it

After execution, RPOR6 (which is the Uart_3_Tx_PPS_Output_Register) contains 0x1C06

This is from the inc file that is used to create the masks and patterns. (I try to avoid hard coding numbers in the source files which have the actual instructions.)

 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 ;;                                                                                         ;;
 ;;                                                                                         ;;
 ;;    Map UART # 3 Tx Pin                                                                  ;;
 ;;                                                                                         ;;
 ;;    Docs for this are: Manual DS39975A                                                   ;;
 ;;                                                                                         ;;
 ;;    Find "TABLE 2: COMPLETE PIN FUNCTION DESCRIPTIONS FOR 100-PIN DEVICES"               ;;
 ;;    in Manual DS39975A, Page 8, where We find the secret PIC Pin Names for               ;;
 ;;    the actual physical pin numbers                                                      ;;
 ;;                                                                                         ;;
 ;;    TABLE 10-4: SELECTABLE OUTPUT SOURCES (MAPS FUNCTION TO OUTPUT)                      ;;
 ;;    Page 160, We find the output function numbers                                        ;;
 ;;                                                                                         ;;
 ;;                                                                                         ;;
 ;;                                                                                         ;;
 ;;                                   PIC     Associated             Output                 ;;
 ;;    Circuit           Physical     PIN     Control       Actual   Func.                  ;;
 ;;    Function          Pin          NAME    Reg           Bits     Number                 ;;
 ;;    ------------      ------       -----   -------       ----     -----                  ;;
 ;;                                                                                         ;;
 ;;    UART #3, TX       Pin 23       RP13    RPOR6         3F00     28         Output      ;;
 ;;                                                                                         ;;
 ;;                                                                                         ;;
 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

I combined that knowledge with these notes from the family data sheet to create the constants with meaningful names.

    .Equiv  Uart_3_Tx_PPS_Output_Register,  RPOR6           ;Register 10-35, Page 177
    .Equiv  Uart_3_Tx_Reg_Control_Bits,     0x3F00          ;Look for "RP13R" in the big include file               ;;;DEBUG DEBUG Date: 2013-02-05  Time: 20:47:02  
    .Equiv  Uart_3_Tx_Output_Func_Number,   28              ;From Table 10-4, P. 160

    .Equiv  Uart_3_Tx_And_Off_Bit_Pattern,                  ~(Uart_3_Tx_Reg_Control_Bits)
    .Equiv  Uart_3_Tx_Or_In_Bit_Pattern,                    ( Uart_3_Tx_Output_Func_Number << RP13R0 )

From the File: "p24FJ256GB210.inc" (no quotes)

 ;----- RPOR6 Bits -----------------------------------------------------
         .equiv RP12R0,  0x0000
         .equiv RP12R1,  0x0001
         .equiv RP12R2,  0x0002
         .equiv RP12R3,  0x0003
         .equiv RP12R4,  0x0004
         .equiv RP12R5,  0x0005
         .equiv RP13R0,  0x0008    ;;; <<<<<----- RP13 is in the right place
         .equiv RP13R1,  0x0009
         .equiv RP13R2,  0x000A
         .equiv RP13R3,  0x000B
         .equiv RP13R4,  0x000C
         .equiv RP13R5,  0x000D

After all is said and done, with or without RTS or CTS enabled, the PIC on the other side of the UART apparently never sees the first byte that I put in on this side.

Does anyone see anything where I put the wrong bit in the wrong place ?

At this moment, I cannot confidently answer yes or no to this question: Is the UART #3 TX function correctly connected to physical Pin 23 on a 100-Pin TQFP configured PIC24FJ256GB210 ?

Thanks a ton if you can identify what's going on here.

Answer 1

Here is where I found the error and the answer to the problem

Look at special function register U3STA

Look for the bit UTXEN

It must be set.

If not, you will fill the FIFO and clog it up after the 4th byte.

The UTXEN is bit #10. The assembler and compiler will probably change it to #2 in the next higher numbered byte.

Answer 2

There is a errata issued from MicroChip about this behaviour on PIC24 microcontroller. refer: http://ww1.microchip.com/downloads/en/DeviceDoc/80522c.pdf.

Page 4 of the document indicates that:

Module: UART (TX Buffer)
If the transmit buffer is filled sequentially with
four characters, the characters may not be
transmitted in the correct order. 
Work around
Do not completely fill the buffer before transmit-
ting data; send three characters or less at a
time.

Another work arround is suggested by a developer to use the TRMT flag instead, refer to: http://www.microchip.com/forums/m622420-print.aspx

Hope it helps.

Answer 3

My local hardware expert says that if I turn off flow control that the bytes will go out no matter what.

Yes, that's true. But that takes time, serial ports are very slow. Getting one byte transmitted from the fifo takes an eternity, about a millisecond at 9600 baud. Which is why UARTs are normally fed from a larger buffer by an interrupt handler.