LP-AM261: Problem with PRU not receiving properly

Akira Higuchi

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.

2 months ago

0 Dhaval Khandla 2 months ago

TI__Mastermind 28504 points

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

0 Akira Higuchi 2 months ago in reply to Dhaval Khandla

Prodigy 30 points

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

0 Dhaval Khandla 2 months ago in reply to Akira Higuchi

TI__Mastermind 28504 points

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

Regards

Dhaval

0 Akira Higuchi 2 months ago in reply to Dhaval Khandla

Prodigy 30 points

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.

0 Dhaval Khandla 2 months ago in reply to Akira Higuchi

TI__Mastermind 28504 points

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

0 Akira Higuchi 2 months ago in reply to Dhaval Khandla

Prodigy 30 points

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.

0 Dhaval Khandla 2 months ago in reply to Akira Higuchi

TI__Mastermind 28504 points

Akira Higuchi said:
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).

Akira Higuchi said:
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

0 Akira Higuchi 2 months ago in reply to Dhaval Khandla

Prodigy 30 points

Hi Dhaval,

Dhaval Khandla said:
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

0 Dhaval Khandla 2 months ago in reply to Akira Higuchi

TI__Mastermind 28504 points

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

0 Akira Higuchi 2 months ago in reply to Dhaval Khandla

Prodigy 30 points

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

0 Dhaval Khandla 2 months ago in reply to Akira Higuchi

TI__Mastermind 28504 points

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

0 Akira Higuchi 2 months ago in reply to Dhaval Khandla

Prodigy 30 points

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

+1 Dhaval Khandla 2 months ago in reply to Akira Higuchi

TI__Mastermind 28504 points

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

0 Akira Higuchi 1 month ago in reply to Dhaval Khandla

Prodigy 30 points

Dear Dhaval,

Thank you for your support.
I followed your advice and can confirm that it is now working correctly.

Best regards,
Higuchi

Arm-based microcontrollers

Arm-based microcontrollers forum

LP-AM261: Problem with PRU not receiving properly