• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 193 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.

AM2434: PRU missing rgmii receive data

Lucas Rees
Prodigy 60 points

Part Number: AM2434

Hi,

continuing from this https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1505525/am2434-pru-icssg-rgmii-rx_tx-taskmanager-not-working-correctly :
im still facing problems receiving more than 96Bytes over rgmii. The issue seems to be that the nb_task is sometimes not called, which causes the application to lose 32byte blocks. Please provide a working example for up to 256bytes.

Best regards

Lucas

 

  • 0
    TI__Expert 8450 points

    Hi Lucas,

    Currently, I am away from office till end of week. Please expect a delay in the response till then. Meanwhile, I will loop this thread with the development team to check if any suggestions can be made.

    Thanks and regards,
    Teja.

  • 0
    Prodigy 60 points

    I found the solution to that problem: CORE_VBUSP_SYNC_EN bit of the ICSSG_CORE_SYNC_REG needs to be set.
    This causes the taskmanager to handle the incoming rgmii rx data correctly and not miss any interrupts or bytes. 

    Best regards

    Lucas

  • 0 in reply to Teja Rowthu
    Prodigy 60 points

    Since i found the solution to the first problem i would like to discuss some weird behavoir of the pru that might be related:

    I run the pru rgmii driver on prg0_pru0/pruicss0 and the ethercat tiesc on pruicss1. the rgmii driver is based on the SORTE_G but without the phy code, so basicly its the rgmii and taskmanager setup for transmit and receive. After that the main programm or background task, waits in a busy loop for some signal and than transmits data. Receive is managed by the taskmanager and should be independent of the transmit.

    This code that waits for the signal (3 interrupts from r5f0_1, r5f1_0, r5f1_1):
     wait_for_interrupt:
    ; poll interrupt register
         ldi     r0.w0, 0x0208
         ldi     r0.w2, 0x3002
        lbbo    &r1, r0, 0, 4
        qbne    wait_for_interrupt, r1.b0, 0x07

    Now for the weird behaivor: the received data is completely fine until the ethercat driver with manual mdio and tiesc are loaded into pruicss1, after that the receive data seems to be overwritten by some reoccouring values sometimes in timeframes between ~200us and 11ms (rgmii data beeing send and received every 20us). The data is received fine and loaded into the pru register r2-r9, but the data pushed into memory by xfr2vbus or sbbo instruction (tested both) differs from the data seen in the registers before. I changed the memory location from msram to pru local ram but no difference in what overwrites the data, also placing hardware breakpoints on the memory location doenst seem to notice any write from r5f cores that might overwrite the data.

    Replacing that 4 line polling with the direct offset load fixed the issue:
    wait_for_interrupt:
    ; poll interrupt register
        lbco    &r1, c6, 0x08, 4
        qbne    wait_for_interrupt, r1.b0, 0x07

    Is there any explanation on what causes this behavoir?

    Best regards

    Lucas

  • 0 in reply to Lucas Rees
    TI__Guru 50821 points
    Lucas Rees said:
         ldi     r0.w0, 0x0208
         ldi     r0.w2, 0x3002
        lbbo    &r1, r0, 0, 4

    These accesses INTC register via external address (and not local which 0x20208) so access goes outside ICSSG to interconnect and depending on arbitration while EtherCAT is running in parallel (R5F stack might be accessing ICSSG DMEM/SMEM cyclically at high rate) - without arbitration itself, latency is 42 PRU cycles or so, with EtherCAT running in parallel, this could be higher and potentially breaking the timing of your custom firmware