PGA460: Issue of communication between multiple devices

Hi Stanley,

Is the non-responsive device always the same device, and does the no response from CMDs 5 and 9 always occur at the same point in the execution sequence, or is the error occurrence random? How much delay does the master controller allow between each CMD 5 and 9 attempt? If the delay time is increased to at least 50ms (for debug) between commands, does this resolve the no response error?

Hi Akeem,

Below is the test cycle flow:

1. Cmd17 makes these three devices measure distance at the same time.

2. Delay 5ms

4. Cmd9 reads the data from dev_stat1 (first device)

5. After receiving response signal from dev_stat1, delay 2ms

6. cm5 reads the measured data from dev_stat1 (2 sets of measured data)

7. After receiving response signal from dev_stat1, delay 2ms

8. cm5 reads the measured data from dev_stat2 (2 sets of measured data)

9. After receiving response signal from dev_stat2, delay 2ms

10. cm5 reads the measured data from dev_stat3 (2 sets of measured data)

The problem always occurs at the step 10. But if customer delay 18ms instead of 2ms at the step 10, this issue will be solved. 

Any clues for this phenomenon? 

Best Regards,

Stanley Dai

Hi Stanley,

What interface is the customer using, and at what speed/baud rate? UART or SPI?

I assume CMD17 is using a preset set with a record length of 4.096ms to allow the ultrasonic burst/listen capture to be completed within 5ms.

The issue may be related to the following statement from the UART section of the PGA460 datasheet:

If the UART interface remains idle in either the logic 0 or logic 1 state for more than 15 ms, then the PGA460-Q1 communication resets and expects to receive a sync field as the next data transmission from the master device.

The above statement is true for both UART and SPI. If there is no command overlap due to the interface, I suspect that when device3 receives a previous command with a different address within 2ms of receiving the latest command with the correct address, device3 is already unintentionally in an idle state. 18ms allows the USART to reset given the 15ms timeout.

Hi Akeem,

So are there anything customer can do to solve this issue or verify it? According to your statements, device3 has already entered idle state before it received the cm5. So is it possible that we reduce delay time to prevent device3 from entering idle state ?

Best Regards,

Stanley Dai

Stanley,

I first want to verify the interface settings. For instance, if they are using UART at a low baud rate, there could be near overlap of the commands when using only a delay a 2ms, which is why device3 may have trouble recognizing its intended command. If not already maximized, set the master controller's UART baud rate to 115.2kBaud without changing the delay to see if this helps.

The theory on the device idle timeout is only additional speculation that I do not want to further explore just yet because there is no option to change the idle state timeout. I have never encountered any bus interface communication errors as you've described, which is why I think the master determined delay between commands is key in debugging this.

Akeem,

The interface setting is UART, and it's baud rate is already 115.2kBuad. And these device is linked together through RS-485 way.

Please refer to the test cycle flow above-mentioned. The dev_stat2 and dev_stat3 will not respond to the command "cm5" occasionally. But the dev_stat1 always works well.

Best Regards,

Stanley Dai.

Hi Stanley,

I am checking with our digital design team if there is a minimum timeout or delay value required for a bus interface topology when using individual address commands.