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.

How long does it take to get the HPI ready in C6455 after power up?

Other Parts Discussed in Thread: OMAP-L138, AM1808, OMAPL138

Here are my steps:

1. Host uploaded DSP code via HPI and then Host asserted HPI DINT bit to wake DSP up. This part is working fine.

2. After DSP woke up and ran its code, DSP code acknowledged HPI DINT bit by writing 0x00000002 to the HPIC register.

3. Then DSP wrote some "ready" message to L1D SRAM at location 0x00F00400, and asserted HINT bit by writing 0x00000004 to the HPIC register.

4. Upon receiving HPI interrupt from DSP, Host read the message via HPI interface, but I read garbage data.

If I added delay (~ 1000 ticks) in between step 2 and 3, Host could read correct message via HPI interface. However this is not a desired solution without knowing for sure how long it takes for the HPI interface to be ready.

I checked both internal HRDY bit as well as HRDY_N pin, and both indicated HPI ready right away after DSP woke up.

So, what is the minimum wait time Host to wait after DSP code woke up before it could access DSP memory via HPI?

Thank you.

  • Hi JImmy,

    I don't think anybody would have done this experiment on C6455.

    However the measurements of the boot times for various boot modes supported by OMAP-L138/AM1808/C6748 and its derivatives are done and projected in TI WIKI.

    I would recommend you to take up the procedure followed for OMAPl138 for measuring the time after power up and try to accomplish in C6455.

    The procedure for omapL138 is given here.

    Try whether you can attempt it for C6455. Try a test case to toggle a GPIO immediately at the start of the first AIS command executed by RBL You have to basically measure the time between the reset and the first toggling of GPIO.

     

    Regards,

    Shankari

    -------------------------------------------------------------------------------------------------------

    Please click the Verify Answer button on this post if it answers your question.
    --------------------------------------------------------------------------------------------------------

     

  • Jimmy,

    This is definitely strange behavior, your sequence of steps are correct. You shouldn't require any delay at all between waking up the DSP and then being able to perform host accesses, at least from a HW standpoint. If you think about it, the HPI is already fully functional right ater reset and during your loading of the code. The fact that you un-stall tthe DSP by sending the DSPINT from the host dosn't change the configuration nor readiness of the HPI interface. Also, the fact that you are using L1D configured as SRAM as your message location eliminates any chances of cache side effects.

    I have a couple follow-up questions

    - Can I assume that the delay added between steps 2 and 3 are on the DSP side, correct?

    - Have you verified the ability to do consistent reads/writes from/to L1D SRAM from the HPI after the delay? Just want to make sure the interface itself is solid.

    - As an experiment, can you eliminate the delay from the DSP side (assuming that's where it is) and instead add it to the host side. in other words, when you receive the host interrupt from the DSP, have the host wait for delay amount before reading the message from RAM.

    - When you say garbage data, are you shure it's garbage and not maybe a shifted version of the expected value or maybe from adjacent locations in RAM? Can you verify this?

    - Is it consistent everytime you boot? Do you get the same garbage value each time? Have you tried filling all L1D SRAM with some sort of pattern, maybe an incrementing value pattern, prior to doing the interrupt to the host?

    These are a couple things I can think of right now. Let me know the ansers to those then we'll take it form there?

     

    Regards,

    -Brad

     

  • Hi Jimmy,

    Do you have any updates?

     

    Regards,

    -Brad

     

  • Hi Brad,

    Thanks for the response.
    No update yet since I moved to a different task.

    The following are responses to your questions as well as an update from me.

    1. - Can I assume that the delay added between steps 2 and 3 are on the DSP side, correct?
    Yes.

    2. - Have you verified the ability to do consistent reads/writes from/to L1D SRAM from the HPI after the delay? Just want to make sure the interface itself is solid.
    Yes, no issue on this part.

    3. Have not had time to try this.

    4. The data looks very random, and the value wasn't consistent on every boot. I haven't tried putting an increment pattern.


    Another thing that I tried was to move the code that writes to the L1D ram & asserts HINT to the init function instead of within Bios Task. This is on the DSP side. The init function was called before starting Bios. I saw the same issue.
  • Jimmy,

    I assume this is still a pending issue. Have you had a chance to try to move the delay to the host side? Also, do you do anything at all with the cache settings? The bootloader is supposed to leave L1D configured as all SRAM, just wanted to check to see if you enable L1D as cache then maybe disable it later.

    Thanks,

    -Brad

  • Found an issue with the L1 cache setting on my Platform.xdc file. Once I fixed my Platform.xdc file, it fixed both HPI issue and NDK issue (e2e.ti.com/.../403674)
  • Jimmy,

    First, I'm glad you found the root cause of your issues. Second, thanks for posting back here with your findings, that makes for a good E2E citizen :)

    -Brad