• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 503 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.

TDA4VM: Ti Sci Lose Pack

Tongxin Wang
Intellectual 520 points
Part Number: TDA4VM

Hello, we found TiSci packet loss in PDK7.03 when Sci_Server was deployed in Mcu1_0. When the problem occurs, Mcu2_0 will get stuck in SciClient (Wait Forver). We suspect that Mcu1_0 did not timely feedback Sci signal, or lost Sci signal. We would like to know how to modify this part of the code to avoid packet loss. The screenshot below is the logic for our Sci_Server to process Sci.

  • 0
    TI__Mastermind 36307 points

    Hello,

    Have you tried running something different on MCU1_0 that has a known working Sciserver so that we can rule out that there is issues with the MCU2_0?

    Regards,

    Erick

  • 0 in reply to Erick Narvaez
    Intellectual 520 points

    Hello,

    Hi, we tried different versions, but now it looks like a problem with Mcu1_0 working with Main Area. We tried the following version:
    1.Mcu1_0 has a high load in the initialization phase, and an I2C interrupt will enter frequently. In this case it is very easy to get stuck in Mcu2_0 SciClientInit, or stuck in ATF Retry.
    2. Normal version in Mcu1_0 initialization phase, with a small probability that Mcu2_0 SciClientInit is stuck, but Mcu1_0 Task is running normally, and Mcu2_0 does not run out of SciClientInit until 90s.
    So we can't tell if it's Mcu1_0 or the Main Area.

  • 0 in reply to Tongxin Wang
    TI__Mastermind 36307 points

    Hello Tongxin,

    Can you please take a look at the recommendations at the end of this ticket:

    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1098838/tda4vm-how-to-avoid-sci-failed-while-booting-by-ospi

    The main point is that if the MCU1_0 has such a high-load during the initialization that it cannot context switch to serve the Sciclient requests, you might need to put some framework in place to wait for the MCU1_0 activity to lower before you allow MCU2_0 to begin servicing. Can you please try this?

    Regards,

    Erick

  • 0 in reply to Erick Narvaez
    Intellectual 520 points

    Hello Erick,

    We find that Two packets of Sci signals are sent to Mcu1_0 at the same time. Mcu1_0 disables the interrupt after the first interruption and waits for the completion of the Sci Task before re-enabling the interrupt. In this case, the second packet of Sci cannot be processed. How to solve this problem.

  • 0 in reply to Tongxin Wang
    TI__Mastermind 36307 points

    Hello,

    Tongxin Wang said:
    We find that Two packets of Sci signals are sent to Mcu1_0 at the same time.

    Are these two packets from different cores? If the same core would be sending requests to the SciServer, I would expect that the server could handle them all. How many cores are issuing requests? You mentioned that there is also an I2C driver running on MCU1_0, is this running as a separate task?

    Regards,

    Erick

  • 0 in reply to Erick Narvaez
    Intellectual 520 points

    Hi：

    These two packets are from two different Cores.

    All Cores which are in Main Area will send Sci Request to Mcu1_0 within a very close period of time.

    I2C interrupt is in Mcu1_0 and We have ruled out the problem with I2C. 

  • 0 in reply to Tongxin Wang
    TI__Mastermind 36307 points

    Hello Tongxin,

    I've spoken with some of our developers and they mentioned that there should be no reason the server can't handle all of it's requests.

    What OS are you running on the other cores running in your system?

    The reason I ask is to see if you could test the SciServer implementation we provide as the default firmware that is loaded in a multi-core boot. If you need to run AUTOSAR across multiple cores, perhaps this won't be possible.

    If our firmware can handle the requests, we could then dive into the details of your implementation to see what could be holding back the server.

    If your firmware also can't handle the requests, we can try to replicate this issue on our side to have the development team take a look.

    Thanks,

    Erick