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.

TDA3XEVM: Active I2C Traffic Suspends NetworkTx Ethernet Output

Part Number: TDA3XEVM
Other Parts Discussed in Thread: AWR1243

Hi,

We have attached a second I2C slave device in addition to the AWR1243 from the perspective of the TDA3 controller over the I2C line embedded in the FPDLink.

We have created a Link to communicate with this I2C slave device. For each radar frame captured by IssCapture Link, IssCapture will trigger this device Link to send an I2C request to the slave device. So the I2C line is active on a per frame basis. We observed that when the I2C line is active, requesting any network TX to output RDM frames from the Chain will be suspended until we stopped the I2C request to the slave device. This behavior is reproducible and can be demonstrated. This is a very URGENT case where it needs to be resolved.

Thanks,

--Khai

  • Hi Kahi,

    experts are looking at this and will reply here soon.

    Regards,

    Yordan

  • Khai

    Can you please elaborate, how you are achieving the below?

    "IssCapture will trigger this device Link"

    Thanks and Regards

    Piyali

  • It sounds like this device link handling I2C request is blocking the whole chain from running.

    How does IssCapture link talk to this device link? Please make sure it is not blocking IssCapture Link from sending data to the Network Link.

    Regards,
    Stanley

  • Hi Stanley/Piyali,

    Thanks guys for taking my E2E ticket.

    What you mentioned would have been correct if I don't get anything display on the local HDMI output which is showing the RDM heatmap from the FFT processing. I have 2 paths for the processing output - the HDMI and the Ethernet output. HDMI shows the RDM from the frame data at framePeriodicty interval while if request for network output, the network RX TCP requests to the server won't show up until I manually stopped the I2C activity.

    It's hard to believe I2C traffic would suspend network traffic but it's happening. I would like to schedule a Conf Call if you guys are available so I can show you.

    Thanks,

    --Khai

  • The problem is most likely in the device link code. You can put some trace to see during your I2C device link call if Network Link was able to run at all.

    I2C traffic shouldn't have any impact on the Network traffic.

  • Stanley,

    I have done all that already. I wouldn't have bug you guys to help me debug my own code. It looks to be a framework issue.

    How do you explain I got HDMI to display RDM while this I2C device is active and no Ethernet output?

    Thanks,

    --Khai

  • Display will keep displaying the last frame even when there is no more frame coming from input source.

    Could you please share what you have done so far to debug the device link?

    Also, please share your use case data flow.

  • Hi Stanley,

    Would be much easier to have a conf call to go over this, wouldn't you agree? If so, I need some time to set it up with the HW in the car to show you what I am seeing. Please let me know if you can do it tomorrow 3:00PM TX time.

    Thanks,

    --Khai

  • FYI, the HDMI display wasn't frozen while I2C line was active. Just no Ethernet output.

  • Notes from the debug session...

    The issue seems to be the SYNC Link is blocking frames from going to Network Link when I2C Device Link is actively sending I2C command.

    This is because I2C communication was called inside Capture Link at the end of frame process and incurred 120+ms delay.

    With this long delay, the SYNC Link could have problem to match timestamp from Capture Link output frame and FFT Link output frame.

    As a result, no frame is passed to Network Link from SYNC Link when I2C transfer is active.

  • Hi Stanley,

    Thank you much for the help in troubleshooting the problem. That was the exact problem and extending the time delta threshold for the SynLink fixed the problem for now.

    Problem solved!!!

    --Khai