UART 3 will not accept 5th byte

Question

The chip in question - PIC24FJ256GB210

This is a 100-pin TQFP form factor.

We have an embedded system with two microprocessors.

Two microprocessors use UART for communication, which (for me) is displayed on UART # 3 on the PIC24.

I put 4 bytes in UART # 3. Everything is fine. 5th byte will not enter.

I say FIFO backup.

My local hardware expert says that if you turn off flow control, bytes will come out no matter what.

It's true? I had never heard that before. I thought it was a hardware signal on the other hand; that is, the read signal must occur on the other hand before the FIFO buffer allows the room on that side.

Its definition of "disable flow control" is not to use PPS (peripheral pin selection) to map RTS (send request) or CTS (Clear To Send) contacts to their corresponding physical contact on the board.

I have done it. Result: no change; FIFO buffer is still full. The "#UTXBF" bit is never cleared after the fourth byte is entered.

I have a schematic diagram with physical conclusions, numbered and labeled.

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

I accurately and accurately map UART # 3 contacts to how I map UART # 2 and UART # 1, and both of the other two work fine.

As long as the numbers are different, the sequences of commands are identical. The numbers correspond to the contacts.

I am debugging this a third time, observing every bit in each register and comparing them with 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 the MpLab disassembler window, where the operation codes 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 all there is to it 

After executing RPOR6 (which is Uart_3_Tx_PPS_Output_Register ) contains 0x1C06

This is from the inc file, which is used to create masks and templates. (I try to avoid hard encoding numbers in source files that have 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 this knowledge with these notes in the family data sheet to create 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 file: "p24FJ256GB210.inc" (without 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 everything is said and done, with or without RTS or CTS , the PIC on the other side of the UART, apparently, never sees the first byte that I inserted on this side.

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

At this moment, I can’t answer the yes or no question with confidence: is the UART # 3 TX function correctly connected to physical pin 23 on the 100-pin TQFP PIC24FJ256GB210 configured?

Thank you if you can determine what is happening here.

Answer 1

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

Look at the U3STA Special Function U3STA

Find the UTXEN

It must be installed.

If not, you fill in the FIFO and hammer it after the 4th byte.

UTXEN is bit # 10. The assembler and compiler are likely to change it to # 2 in the next higher byte.

Answer 2

MicroChip has a fix for this behavior on the PIC24 microcontroller. see 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 developer recommends using the TRMT flag, namely: http://www.microchip.com/forums/m622420-print.aspx

Hope this helps.

Answer 3

My local hardware expert says that if you turn off flow control, bytes will come out no matter what.

Yes it's true. But it takes time, serial ports are very slow. Getting one byte transmitted from fifo takes forever, about a millisecond at 9600 bauds. This is why UARTs are usually served from a larger buffer by an interrupt handler.