• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 98 subscribers
  • Views 1544 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.

TMDXIDK437X: PRU peripheral interface receive issue

Benjamin Franke
Prodigy 50 points

Part Number: TMDXIDK437X

Hi,

I use the Peripheral Interface of the PRU on AM437 to receive asynchronous data that is send from another PRU on the same controller. I send data at a clock of 100kHz and the receiver runs at 800kHz so that I have 8x oversampling. Means, when I send 8 bits I should receive 64.

My problem is that I don't receive 64 but 128, so always twice as much as expected.

I built the receive routine as described in the data sheet. I already changed clock rates, switched the PRUs, switched channels in the peripheral interface and also used another controller to send data, but I always get the same effect.

I tried to analyze the effect I as good as I can, here is how far I've come:

I always send 2 bytes of the same byte, from "0x01 0x01" to "0xFF 0xFF". I doubled the bytes to find out if the bytes I receive are random and just twice as much as I sent or if there is another effect. Here is an example. I send the bytes 0xA3 0xA3, so what I should find in the memory of my receiver (with 8x oversampling) is:

FF 00 FF 00 00 00 FF FF   FF 00 FF 00 00 00 FF FF desampling to 10100011 10100011 or 0xA3 0xA3.

And here is what I actually got:

FF 00 00 00 FF 00 FF 00 00 00 FF 00 00 00 FF FF FF 00 FF FF FF 00 FF 00 00 00 FF 00 00 00 FF FF 00 00 FF FF

This looks random, but you can find the wanted result in it, as I marked in the following:

FF 00 00 00 FF 00 FF 00 00 00 FF 00 00 00 FF FF FF 00 FF FF FF 00 FF 00 00 00 FF 00 00 00 FF FF 00 00 FF FF

If you take the red parts out and put the rest together, you have the result you actually want. As I said, I tested this for bit combinations from 1 to 255 and you can apply this pattern to all of them. Receive twice as much as I want and always four bytes wrong, for bytes correct, four bytes wrong and so on...

This is what I found out, but I can't explain why this effect appears or how to get rid of it. Can you help me?

Best regards,

Benjamin

Board: AM437x Industrial Development Kit (IDK)

CCS-Version:  7.2.0.00013

Compiler-Version: TI v2.1.5

  • 0
    TI__Guru**** 393215 points
    Hi,

    What is this "Peripheral Interface of the PRU on AM437"? The IEP or something else? Please describe in details how you send and receive data and which PRU pins you use.
  • 0 in reply to Biser Gatchev-XID
    Prodigy 50 points
    Hi,

    It is the module that supports EnDat 2.2 and BiSS, it is called Peripheral Interface in the data sheet. It is not the IEP. I send data by filling the FIFO and then setting tx-channel_go in r31. To receive data, I poll on the valid flag in r31 and copy one byte of data from rx_data_out0 in r31. The pins I use:
    pr0_pru0_gpo1
    pr0_pru1_gpi9

    Best regards

    Benjamin
  • 0 in reply to Benjamin Franke
    TI__Genius 10440 points
    Benjamin,

    Do you have a logic analyzer so we can see what is actually happening on the wire? That should narrow down if this is a TX issue or an RX issue correct?

    Jason Reeder
  • 0 in reply to Jason Reeder
    Prodigy 50 points

    Hi,

    I looked on the wire with a logic analyzer as well as with a scope. The signal on the wire is exactly what I sent. I think this is a receiver problem.

    Best regards,

    Benjamin

  • 0 in reply to Benjamin Franke
    TI__Genius 10440 points
    Thanks for the confirmation Benjamin.

    Are you able to share your code, or at least your PRU ED register settings? I am trying to compare this to our EnDat implementation to check for any deltas.

    You are probably aware of this already, but an EnDat example is available in our Industrial Drives package (software-dl.ti.com/.../index_FDS.html) in the interfaces/endat_master/firmware/endat_main.asm file.

    Jason Reeder
  • 0 in reply to Jason Reeder
    TI__Genius 10440 points
    The endat_main.asm file has an example of how to receive and downsample the incoming data in the M_OTF_RECEIVE_DOWNSAMPLE_AND_CRC macro. This does not explain your extra bytes that you are receiving, but might give pointers on checking and clearing the valid bit.

    Below are the registers from the PRU after running the endat_diagnostic program in the Industrial Drives package and having an EnDat2.2 encoder detected. This example (after detecting the EnDat2.2 encoder) set the TX clock to 8MHz and the RX clock to 64MHz. You may be able to compare these settings to your own to see if anything looks off.

    ED_P0_RXCFG - 0x000260E0
    0x00020007
    rx_div_factor=3
    div_frac=1
    uart_clk
    OS = 8

    ED_P0_TXCFG - 0x000260E4
    0x00170700
    tx_div_factor=24
    div_frac=1
    endat_clock_pin=1
    ready
    uart_clk

    P0_CFG0_0 - 0x000260E8
    0x001DF800
    swap=0
    override_en=0
    rx_frame_size=29
    tx_frame_size=31
    tx_wire_dly=0

    ED_P0_CFG1_0 - 0x000260EC
    0x00FA07D0
    rx_en_counter=250
    tst_delay_counter=2000

    R30
    0x0008AC00
    clk_mode=free_running_stop_high
    tx_chan_sel=0

    Jason Reeder
  • 0 in reply to Jason Reeder
    Prodigy 50 points

    Hi,

    I didn't know the endat_main.asm file before. I looked at the macro and I think I check and clear the valid bit in the right way. I mustn’t post my code here, but if you need it, to find a solution, I think I can send it to you via E-Mail.

    But I checked my registers and I think they are mostly equal. Her are my results:

     

    ED_P0_RXCFG = 0x00000007
    OS = 8

    ED_P0_TXCFG = 0x077F0700
    tx_div_factor = 1919
    div_frac = 1
    endat_clock_pin = 1
    ready
    uart_clk

    P0_CFG0_0 = 0

    ED_P0_CFG1_0 = 0

    R30 = 0
    clk_mode = free_running_stop_low
    tx_chan_sel = 0

     

     

    ED_P1_RXCFG = 0x00EF0007
    rx_div_factor = 239
    div_frac = 1
    uart_clk
    OS = 8

    ED_P1_TXCFG = 0x00000700
    endat_clock_pin = 1
    ready
    uart_clk

    ED_P1_CFG0_1 = 0

    ED_P1_CFG1_1 = 0

    I configured the register for 100kHz send-clock and 8x oversampling. For transmit I use P0 and for receive P1. I send in continuous mode, so I don’t need TX framesize and I also don’t use wire delay, so I left CFG0 and CFG1 at 0.

    Best regards,

    Benjamin

  • 0 in reply to Benjamin Franke
    TI__Genius 10440 points

    Benjamin,

    Nothing jumps out as incorrect in your register settings. Can you reach out to your field partner to share the code with me?

    Out of curiosity, if you ignore (immediately clear) every second data valid flag, do you receive the correct data stream?

    There is one comment in the endat_main.asm code about waiting at least two cycles before checking the data valid bit (after you clear it). Do you have at least two cycles delay before checking the valid bit again, or is this in a very tight loop?

    Jason Reeder

  • 0 in reply to Jason Reeder
    Prodigy 50 points

    Hi,

    your last idea solved my problem. I worked with a very, very tight loop. Now I added some wait cycles and I get exacty what I expected to receive. Thank you for this advice.

    Maybe you should add this information to the data sheet, to the EnDat RX example, because that's where I based my implemetation on and just didn't know about this spec.

    I'm really glad you mentioned that spec and finally solved my problem. I struggled with this one for quite some time. Thank you for your support.

    Best regards,

    Benjamin

  • 0 in reply to Benjamin Franke
    TI__Genius 10440 points

    Benjamin,

    Thanks for coming back and confirming the answer!

    I've given feedback that we need to update the data sheet and this should make its way into a future release.

    Jason Reeder