LP-AM261: Problem with PRU not receiving properly

Part Number: LP-AM261


Hello.

I am working in the following environment:

  • Device: AM261x LaunchPad
  • SDK: motor_control_sdk_am261x_10_02_00_07
  • IDE: CCS 12.8.1

On a custom board using PRUICSS, I am running a configuration where the signal output from PRU0’s TX output port (PR0_PRU0_GPIO1) is routed to an external pin and then looped back on the board to PRU1’s RX input port (PR0_PRU1_GPIO9).
Both PRU0 and PRU1 are configured with the 3-Channel Peripheral Interface Mode for their Mux Mode.

When running this setup, I transmit an 32-bit value from PRU0, but PRU1 receives a different value, as though the bit positions were shifted.

For example, when transmitting 0xFF1234FF:

  • Transmitted data: 0xFF1234FF = 11111111000100100011010011111111b
  • Received data: 0x07F891A7 = 00000111111110001001000110100111b

It behaves as if several zeros are received first, and then the transmitted data appears afterward.

Question:
Is there any way to avoid the phenomenon where zeros are received during the idle state?

Thank you for your support.
Best regards.

  • Hi

    Are you using a custom firmware, or firmware from SDK?

    What is the start bit polarity triggered for the receive interface? This can be checked in ICSSM_PR1_CFG_SLV_PRU[0/1]_ED_RX_CFG_REG register. Can you share the value configured in this register?

    Regards

    Dhaval

  • Hi Dhaval,

    I'm using a custom firmware.
    For the receive interface configuration, the PRU0_ED_RX_SB_POL field in the ICSSM_PR1_CFG_SLV_PRU[0/1]_ED_RX_CFG_REG register is set to 0.

    Best regards.

    Higuchi

  • Hi

    Can you share the logic analyzer/scope capture of Tx and Rx pins? Which firmware are you using to send the data?


    Regards

    Dhaval

  • This is a capture when 0xFF1234FF is sent to Tx.
    Since a loopback connection is used, there is no capture of Rx.

    The firmware used is customized based on the SDK firmware.

  • Hi

    Start bit is configured for 0, so the RX interface will start as soon as it sees 0 on RX. Isn't the idle state supposed to be high in this case? Otherwise how do we define when to start the capture?

    Regards

    Dhaval

  • I captured waveforms with the PRUn_ED_RX_SB_POL bit in the ICSSM_PR1_CFG_SLV_PRU0_ED_RX_CFG_REG and ICSSM_PR1_CFG_SLV_PRU1_ED_RX_CFG_REG registers set to 0 and 1.
    The results were the same in both cases, with no change in the start bit on the Tx side.
    Also, the received data on the Rx side had misaligned bits.

     

    (1) When PRUn_ED_RX_SB_POL is set to 1:

     

    (2) When PRUn_ED_RX_SB_POL is set to 0:

     

    Questions:
    1. Is setting the RX_SB_POL bit to 1 the way to set the start bit of the Rx interface to 1?
    2. Is it possible to set the idle state signal of the Rx interface high using the PRU settings? If so, please tell me how.

  • Hi

    1. Is setting the RX_SB_POL bit to 1 the way to set the start bit of the Rx interface to 1?

    It depends on when you want the PRU to start capturing data in the receive interface. After RX is enabled in the three channel interface, it will start sampling as soon as it sees the start bit (polarity of start bit is configured using RX_SB_POL).

    Is it possible to set the idle state signal of the Rx interface high using the PRU settings? If so, please tell me how.

    RX is a digital input to PRU 3 channel interface - so we can not modify this on receive side. From the transmit side, it should be idle high/1 if we want to configure start bit of low/0.

    If you have additional questions, please let us know.

    Regards

    Dhaval

  • Hi Dhaval,  

    From the transmit side, it should be idle high/1 if we want to configure start bit of low/0.

    I want the start bit to be low/0, so please tell me how to make the idle state high/1 from the transmitting side.

    Best regards.

    Higuchi

  • Hi

    This would depend on what firmware are you using to transmit the data? Are you using any firmware from TI SDK? We need to ensure the TX firmware keeps idle high.

    Regards

    Dhaval

  • Hi Dhaval, 

    The firmware is reused from source/position_sense/nikon/firmware in TI SDK, and the sending logic is the same as TI SDK.

    Best regards.
    Higuchi

  • Hi

    In this case, you will have to update the Nikon firmware to continuously send 1.

    As per Nikon spec, the TX line does not have to be high continuously. So the SDK firmware will not keep TX line high.

    Regards

    Dhaval

  • Hi Dhaval,

    The SDK version I am using is motor_control_sdk_am261x_10_02_00_07.
    Is there any firmware, including other SDK versions, that keeps the TX line high?
    If such firmware exists, please let me know.

    Best regards.
    Higuchi

  • Hi

    We do not have any SDK firmware, which keeps TX high always as standard encoder interface does not have such requirement.

    You can modify Nikon firmware TX logic to keep sending "1" continuously in idle state. After command is sent, you can keep pushing 1s into FIFO. You can keep checking FIFO fill level and when FIFO has space, push more data.

    Regards

    Dhaval