• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 98 subscribers
  • Views 515 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.

HPI boot in new OMAP137

daisy wu
Prodigy 130 points

Hello everyone,

       I have a question need to be solved.   Nearly  I bought  an OMAP137BZKB3,   which is different  from the older OMAP137ZKB3.  Then my old program cann't run properly,  which is stuck in HPI boot part.  Is there any difference between the two versions that will influence the HPI  boot ? 

      Any help would be appreciated.  Thank you!

  • 0
    Prodigy 130 points

    ps:   the program has  been downloaded in DSP  by host, and it already ran , but the host couldn't read DSP's data through HPI. 

  • 0 in reply to daisy wu
    TI__Guru 62975 points

    Daisy,

    Can you check this other thread to see if your issue might be related: http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/59660/214894.aspx

    -Tommy

  • 0 in reply to tlee
    Prodigy 130 points

    Tommy,

        It's not the same as the thread  you mentioned before.  DSP program  has been downloaded by host and it ran properly,  but after that the host couldn't  access DSP via HPI,  it seems like HPI has been disabled.  But using JTAG boot,  DSP and host  can communicate correctly through HPI.

    -Daisy

  • 0 in reply to daisy wu
    TI__Guru 62975 points

    Daisy,

    Upon exit of the ROM-based boot loader, I think HPI is disabled.  The user boot application that is executing out of DSP should perform a complete HPI initialization on its own.

    -Tommy

  • 0 in reply to tlee
    Prodigy 130 points

    Tommy,

         but I have already added HPI initialization in the boot program,   is there something wrong with my procedure as below?

        //  pin multiplexing setup

        PINMUX13 = 0x44111111;  // HPI / McASP1
        PINMUX14 = 0x22444444;  // HPI
        PINMUX15 = 0x41222222;  // HPI
        PINMUX16 = 0x11111114;  // HPI
        PINMUX17 = 0x00104111;  // HPI
        PINMUX18 = 0x22212221;  // HPI
        PINMUX19 = 0x00000002;  // HPI

        CFGCHIP1     &= 0xFFFEFFFF;                               //HPIBYTEAD=0
        CFGCHIP1     |= 0x00008000;                                // HPIENA=1
        HPI_HPIC = 0                                                              //HPI control register                                                  

                 |( 1 << 9 )                                                     //Dual HPIA mode operation is enabled.
                 |( 1 << 3 )                                                     //reserved bit.
                 |( 0 << 0 );                                                     //First halfword is most significant.

        HPI_PWREMU_MGMT = 0;  
            HPI_HPIAW =0x80000000;                           //initial addresses
        HPI_HPIAR =0x80000000;

        HPI_HPIC &=0xFFFFFF7F;                                  //HPIRST=0                       

  • 0 in reply to daisy wu
    TI__Guru*** 125430 points

    daisy wu said:
        CFGCHIP1     &= 0xFFFEFFFF;                               //HPIBYTEAD=0

    Why do you set HPIBYTEAD=0 (word addressing)?  I believe for boot it uses byte addressing which is more natural since this device is byte-addressable.  Is your host shifting all addresses by 2 bits to compensate?  If not, your writes aren't going where you think.

  • 0 in reply to Brad Griffis
    TI__Guru* 83855 points

    Daisy

    To extend on what Tommy and Brad said, the ROM code in Rev 2.0 silicon tries to put back the CFGCHIP1 register values for HPI back to the power on reset values upon HPI boot rom function close. So it sets HPIBYTEAD and HPIENA back to 0. ROM code in Rev 1.0 does not do this, and leaves HPIBYTEAD and HPIENA as 1.

    Hopefully this difference , is what is causing a difference in behavior on your setup.

    Regards

    Mukul

  • 0 in reply to Brad Griffis
    Prodigy 130 points

    Brad, 

           You're right. My problem is solved. Thanks a lot.

           Also thanks tommy,  you give me quite important information.