• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 31 subscribers
  • Views 139 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.

AM263P4-Q1: AM263P4- I2C driver hangs after device conversion to HS-SE

Sebastien Chapeau
Intellectual 290 points
Part Number: AM263P4-Q1

Tool/software:

Hi

I'm encountering an issue with the I2C driver hanging in I2C_lld_probe function when reaching line #1234 Clock_uSleep.

The exact same code works very well on a launchpad non HS-SE device but not on the one I recently converted to HS-SE to work with the HSM.

Is there anything that would prevent the CPU to execute ClockP_sleepTicks to execute correctly ?

Many thanks

Regards

Seb

  • 0
    TI__Genius 16642 points

    Hi Seb,

    Im not sure if this has anything to do with the device being HS-SE. Can you please share your function call stack screenshot when it hangs here. 

    Is the code running on HS-FS and HS-SE devices exactly the same? Even the syscfg files?

    Regards,
    Shaunak

  • 0 in reply to Shaunak Deshpande
    Intellectual 290 points

    Hi

    I found out the cause of the problem but diod not quite get to the bottom of why.

    What happened if that when testing the AES examples in the TIFS, the HSM image got rebuilt.

    That was preventing the SemaphoreP_pend() function to work. This was called from ClockP_sleepTicks(). The function got stuck in the while loop.

    Rebuilding the HSM image from the getVersion example, the issue was solved. I noticed the HSM header file containing the image had changed.

    Especially the line showed below in red was indicating the image was coming from when I built the example.

    I could not get to the bottom of it. I don't understand why the HSM image not being correct would have an influence on the ClockP_sleepTicks() function.

    I would appreciate to have an explanation on this if possible.

    Otherwise, since HSM image rebuilt, the code works as it used to.

    Thanks.

    Regards

    Seb

  • 0 in reply to Sebastien Chapeau
    TI__Genius 16642 points

    Hi Seb,

    What I can think of is that the HSM services needed for the AES example to run are a bit different than what is needed to run the I2C Code on R5F core. I'm guessing the AES example used from TIFS SDK was for M4F core? If that is the case then the services for R5F core are not configured. The semaphore_pend() function expects someone to post the semaphore, but due to updated hsmImg, the R5F interrupt didn't get serviced.

    Regards,
    Shaunak