PIC32 receives/transmits improper data on serial port

Question

I have referred http://microchipdeveloper.com/harmony:example-usart-dynamic-wf32 to configure the UART and send/receive data between PC(Putty) and my PIC32MZ.

The demo program in the link receives the data, adds one to it and transmits it back to putty.

    case APP_STATE_RX:                          // USART receive state
    {   
        // if byte received in USART instance pointed to by myUSARTHandle (USART1 in this case)
        if (!DRV_USART_ReceiverBufferIsEmpty(myUSARTHandle))
        {
           appData.rx_byte = DRV_USART_ReadByte(myUSARTHandle); // read received byte
           appData.tx_byte = appData.rx_byte + 1;  // modifying received byte confirms it was received
           appData.state = APP_STATE_TX;           // change state to TX
        }
        break;
    }

    case APP_STATE_TX:                          // USART transmit state
    {
        // make sure the transmit buffer is not full before trying to write byte 
        if(!(DRV_USART_TRANSFER_STATUS_TRANSMIT_FULL & DRV_USART_TransferStatus(myUSARTHandle)) )
        {
            DRV_USART_WriteByte(myUSARTHandle, appData.tx_byte);  // send modified byte
            appData.state = APP_STATE_RX;       // change state to RX and wait for next received byte
        }
    }

However, whenever I enter (transmit) any data from Putty to PIC, the PIC reads it as "ý";0xff.

The PIC code adds 1 to 0xff and sends NULL;0x0 back.

The putty screen is always blank.

How can I transmit/receive proper data between my PIC and pc?

Thanks in advance!

Edit:- I double-checked the clock settings for the UART etc, however every-time I send something from puty (characters or numbers) all I receive in UART_Rx buffer is "ý";0xff.

I would take a step back and verify the bit rates are good by simply sending a readable ASCII character like 'R' back to the PC instead of incrementing. The trouble with 0xff and 0x00 is that they're common values after the C code inits and could hide the nature of the problem. — user201365, Nov 30 '18 at 14:58
Hi isdi, thank you for your comment. Actually I tried sending the letter 'A', 'R', but if produces that same result. I even sent 0x55 and 0xAA alternately, however, everytime I encounter 0xff and NULL. Putty remains blank as always. — Sandrocottus, Nov 30 '18 at 15:27
I'm sorry having a hard time parsing your statement. Do you mean to say that even if try sending a hard-coded 'A' from the PIC (in response to you sending the PIC a character), the putty screen does not show an 'A', but instead it shows nothing or some "junk" character? Remember that some ASCII characters are not really printable. Also your appData.tx_byte is defined as a byte, correct? I noticed you mentioning sending 32 bit data across, binary data will not be "readable". — user201365, Nov 30 '18 at 15:41
This is a common symptom of using different baud rates or other settings on each end. — pjc50, Nov 30 '18 at 15:47
"but instead it shows nothing or some "junk" character?" No, it does not show any junk character. It does not show anything. "Also your appData.tx_byte is defined as a byte, correct? I noticed you mentioning sending 32 bit data across, binary data will not be "readable"." I will be dividing my 4-byte data into 1-byte and then transmit them one-by-one. But that's the later part. Right now, I am facing issue sending only 1 byte data (char). — Sandrocottus, Nov 30 '18 at 15:55
@pjc50, I have added my UART and Putty setting screens in my post. — Sandrocottus, Nov 30 '18 at 16:03
I tried sending the character 'A' from PIC to putty. However, putty screen remains blank. I can see activity on the PIC Tx line on scope, but no data on putty. — Sandrocottus, Nov 30 '18 at 16:07
I'd start even further back, toggling a bit at a known rate to verify the system clock is running at the rate you think it is. — Scott Seidman, Dec 03 '18 at 15:21
Hey @Scott Seidman, Thanks a lot. I had missed out on the "POSCMOD" clock setting. Configured it and now I can see the data in putty as required. — Sandrocottus, Dec 03 '18 at 15:39
Please post an answer so that I can mark it accepted. Thanks a ton once again! — Sandrocottus, Dec 03 '18 at 15:40

score 1 · Accepted Answer · answered Dec 03 '18 at 15:44

For all questions regarding timing, I recommend starting with something dirt simple that confirms all the system clock configurations. Flashing an LED at a known rate is one way to do this.

Clock setup can be tricky, and step 1 is to make sure you got it right. Even if you get your clock config all screwed up, PICs tend to find a mode to start up in. I start pretty much every project making sure I have the clock right.

PIC32 receives/transmits improper data on serial port

1 Answers1