• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 99 subscribers
  • Views 443 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.

AM3359: PRU UART RXFIFOE problem

Jiri Biel
Intellectual 865 points
Part Number: AM3359
Other Parts Discussed in Thread: PROFIBUS

Hello,

we are using AM3359 MPU with PRU-ICSS block.

There we implemented the PROFIBUS protocol which is using PRU-UART peripheral.

The PRU-UART is configured to use no FIFO's and no interrupts.

For handling of receive part we are using LSR register and we are facing following issue there:

1. On first run of PRU everything is working, then we just disable the PRU.

2. For some time PRU is disabled (but communication on PROFIBUS line is still on-going).

3. SOFT-RESET of PRU

4. Loading of PRU-Code, clearing of DRAMs, SharedRAM and L3OCMC

5. Enabling of PRU

6. From PRU-Code, clearing of PRU internal registers (R0-R30)

6. From PRU-Code, reset of RX and TX parts on UART via PWREMU_MGMT register (just writing 0)

7. From PRU-Code, configuring of UART

8. From PRU-Code, unreset of UART via PWREMU_MGMT (just writting 0x6001)

Now we see, that LSR = 0xE1. This means, that RXFIFOE is set, but no other error register is set, which doesn't take sence (because PE, FE or BI is not set).

Also read of RBR is not helpful and we need to reset UART again.

First of all I want to ask, what does it mean that RXFIFOE is set, but no other errors are signalized, because this situation is not described in reference manual.

What is a reason of such a behaviour and how it can be fixed, that already first UART reset starts to work.

With best regards

Jiri

  • 0
    TI__Genius 15920 points

    Hi Jiri,

    Is this PRU & UART reset procedure part of your planned "production code"?  Or is it simply for debug purposes?  Is this behavior reproducible?

    What value is the LSR register before you reset the UART vis PWREMU_MGMT?  

    Regards,

    Melissa

  • 0 in reply to melissaw
    Intellectual 865 points

    Hi Melissa,

    this was planned reset procedure for release until we not saw the problem.

    The problem is comming randomly, but it happens in 70% and more cases.

    Seems that value of LSR before reset is already with RXFIFOE set.

    My understanding now is that UART register values are not comming to default values after PRU SW-reset,

    but what I don't understand is what the PRU peripheral is doing when PRU is disabled. Is it still running?

    Seems, that problem can be fixed with some fixes:

    1. Reset the UART before we disable the PRU (afterwards seems that problem was solved or probability decreased, but this solution is not prefered due to our design)

    2. PRU HW reset (using SOC_PRM_PER_REGS block) before PRU SW-reset (this seems also working)

    3. PRU UART reset several times until RXFIFOE doesn't disappear

    But to choose the correct solution we need to understand why this is happaning and what UART is doing.

    Means, what to do when RXFIFOE is set and no other error bit set?

    With best regards

    Jiri

  • 0 in reply to Jiri Biel
    Prodigy 55 points

    Hi Melissa,

    Answering your question "What value is the LSR register before you reset the UART vis PWREMU_MGMT? "

    Before restart of UART via PWREMU_MGT Register LSR is 0xE3

    the error bit stays through and nothing works after that correctly.