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.

What is the recommended HPI initialization sequence for OMAP-L138?

Other Parts Discussed in Thread: OMAP-L138

In our project (custom board with OMAP-L138 and Spartan6) we have the following HPI initialization sequence (based on section 22.2.8 of OMAP-L138 DSP+ARM Processor Technical Reference Manual):

  1. Configure HPI pinmux
  2. Enable HPI in CFGCHIP1
  3. Set DUALHPIA and HWOB in HPIC (done by FPGA connected to OMAP)
  4. Configure FREE and SOFT bits in PWREMU_MGMT
  5. Release HPI from reset
  6. Verify that everything went correctly by checking if HWOB bit value changed (was written by FPGA)

Is this sequence correct? The problem is that we randomly (in about 4% cases) experience failure in step 6 (HWOB value is invalid) and we wonder if it's caused by some mistake in initialization sequence.

  • Hi Stanislaw,

    Any stabilization delay is provided before checking the change-in value of HWOB bit? Can you increase the stabilization delay and then see whether that 4% failure cases are still reduced...??
  • Yes, before checking HWOB the code waits about 1 second, additionally the check itself is done in a busy loop (it waits forever until HWOB is changed), so I don't think increasing a delay even more would change anything.
  • Can you please refer to this post ?
    e2e.ti.com/.../123391

    How about the HPI ready pin ?
  • I looked at the discussion that you mentioned and it seems to be about HPIRST. In our code HPIRST is cleared in the last step of the initialization, as it's said in section 22.2.8 of OMAP-L138 DSP+ARM Processor Technical Reference Manual. Shall HPIRST be cleared before FPGA sets HWOB and DUALHPIA in step 3?

    About HPI ready pin - unfortunately in our custom board I have no access to HPI pins of OMAP. But section 22.2.6.8 of OMAP-L138 DSP+ARM Processor Technical Reference Manual shows that during Single-Halfword HPIC Cycle UHPI_HRDY line does not change, so I'm not sure how would it help.

    Anyway, I added a code in HPI initialization sequence that resets FPGA (after reset FPGA sets HWOB and DUALHPIA) and checks HWOB value again in case HPI initialization failed the first time. It looks that it helped, now sometimes FPGA is reset twice but after this HWOB bit value is correct. Still, I consider this to be somewhat crude workaround, so I'd be glad for any suggestions for a cleaner solution.