• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 83 subscribers
  • Views 386 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F28388D: RXWAKE flag not working

Davide Plavan
Prodigy 145 points

Part Number: TMS320F28388D
Other Parts Discussed in Thread: SYSBIOS

We are using the RXWAKE flag to detect the end of the frame in UART communication, but sometimes it just doesn't work.

We are sending to the micro a packet of 5 bytes (always the same values from the PC with a python script).

Tha baudrate is about 1Mbit

The RX interrupt reads the incoming bytes in a buffer.

We are using SYSBIOS with a task that checks the RXWAKE flag to detect the end of the frame and process the data in the buffer.

Sometimes, may be 1 every 1000 packets, the flag is not raised after the end of the packet. It is then raised after the following packet and we have two complete packets, 10 bytes, in the buffer.

We double checked everything but it seems to be a problem with the SCI idle-line detection.

  • 0
    TI__Mastermind 25720 points

    Hi Davide,

    You are trying to use idle-line multiprocessor mode but with only 2 devices (the pc and the F2838x), is that correct? Can you scope the signal on the SCIRX pin of the F2838x to verify that in the errored case, the line correctly has an idle time greater than 10 bit widths (~10us) between frames?

    Since you are only seeing this issue a small percent of the time, this could be caused by clock inaccuracies. Which LSPCLK speed are you using? Sometimes the specific baud rate and LSPCLK pairing can introduce error.

    Best Regards,

    Delaney

  • 0 in reply to Delaney Woodward
    Prodigy 145 points

    Hi Delaney, my setup is a bit more complex: the PC is connected on Ethernet with a first F28388 and this is connected by UART with the second F28388. When the first DSP receive an UDP packet, it forwards it on SCIA line to the second DSP.

    Both the DSP have the same UART configuration: LSPCLK is DEVICE_SYSCLK_FREQ / 2 = 100MHz and BRR=12 so the actual baud rate is 961538.

    I scoped the signals and the UART line stays idle for some milliseconds, so way more than the 10 bits period.

    Can you explain better what does it means that "Sometimes the specific baud rate and LSPCLK pairing can introduce error."?

    Best Regards

  • 0 in reply to Davide Plavan
    TI__Mastermind 25720 points

    Hi Davide,

    Every combination of LSPCLK and baud rate setting has a different likelihood of error on the line. Ideally you want to choose a combination that results in 0% error to avoid synchronization issues between the 2 devices communicating. For an LSPCLK setting of 100MHz and baud rate of 961538 bps, the percent error is ~0% though so this shouldn't be a problem in this case.

    How are you checking if the flag is raised in the SYSBIOS task? Are you just polling the RXWAKE flag?

    Best Regards,

    Delaney

  • 0 in reply to Delaney Woodward
    Prodigy 145 points

    Yes, exactly: in the task I check the status of the RXWAKE flag. I also checked that the task is executed regularly every ms with the scope on a physical pin.

    Sometimes the RXWAKE flag is not raised until after the next byte packet that comes 10-20 ms later.

  • 0 in reply to Davide Plavan
    TI__Mastermind 25720 points

    Hi Davide,

    I am not versed in SYSBIOS, but is it possible that another task is clearing the RXWAKE flag before the SCI task gets the chance to exit the polling loop? The following are the possible ways to clear this flag:

    • The transfer of the first byte after the address byte to SCIRXBUF (only in non-FIFO mode)
    • The reading of SCIRXBUF
    • An active SW RESET
    • A system reset

    Best Regards,

    Delaney