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

Problem with NOR boot and debugging 1st level bootloader

Martin Kaul
Prodigy 110 points
Other Parts Discussed in Thread: OMAP-L138

Hi,

currently I perform the initiation of our custom OMAP-L138 board and try to boot an own simply application (flashing led) using the direct NOR boot methode. Running the application in the debugger works but running the application "standalone" from flash does not work.

To localize the problem I debug now the 1st level bootloader of the OMAP-L138 via setting the PC to 0xFFFD0000. The version of the bootloader is d800k004.

At the beginning of the bootloader it reads the register 01C14024h. The value of this register is 0. Later it checks this value. With the value of 0 it make nothing else than endless looping.

I do not find anything about the register 01C14024h in SPRUGM7D. It seems that this is a SYSCFG register. Cause the neightbour register 01C14020h is the Boot-Configuration Register I suppose this register plays also a role while booting.

Is this an hidden register or an missing register in the documentation.

Best regards
  Martin Kaul

  • 0
    Prodigy 110 points

    Hi,

    exists any detailed documentation about the power up behaviour of the OMAP-L138 - which core performs the 1st Level boot. The ARM or the DSP?

    In some documents (SPRAB41B, SPRS586B) I read something about the ARM bootloader. In the OMAP-L138 Reference Guide (SPRUGM7D) I read that the PSC default state of the ARM is SwRstDisable. How can the ARM bootloader works when the ARM is disabled?

    When I connect my debugger (Lauterbach Trace32) to our custom board then it is possible a connection to the DSP core but not to the ARM core. In the debuggers startup script I first have to enable the ARM core via PSC then connection to the ARM is also possible. This behaviour fit to the above statement that the PSC ARM unit is in disabled state.

    Is this behaviour configurable via pins? We have the Experimenter Board TMDXL138LOGICEXP with a SOM that boots from SPI flash. I erased the flash. With this board I can connect the debugger to the ARM core without need to activate it via DSP. I guess that eventually some hardware configuration is different at our custom board and this results in the different behaviour between experimenter board and custom board.

    Best regards
      Martin Kaul

  • 0
    TI__Mastermind 27585 points

    Martin,

    The following two links should help

    http://processors.wiki.ti.com/index.php/Boot_Images_for_OMAP-L138

    http://processors.wiki.ti.com/index.php/OMAP-L1x_Debug_Gel_Files

    Check those out and let us know your results. Thanks

    Jeff

     

  • 0 in reply to jc-ti
    Prodigy 110 points

    Hi Jeff,

    thanks for the reply. We already found the two links. A colleaque checks this.

    I analysed the GEL script and read the result of the bootloader at address 0xFFFF0700. The corresponding error value in 0xFFFF0700 is 2 - in the GEL file this error code is defined with "unknown error" for our revision d800k004.

    The main problem is that the OMAP-L138 register at the address 0x01C14024 returns the value 0. This register is undokumented - it seems that it is an status register cause the bootloader checks if the value of this register is 0x30 or 0x10. If the value is not 0x30 nor 0x10 then it writes the error code 2 and enters an endless loop.

    I checked the behaviour on the LogicPD Experimental board: register 0x01C14024 equals to value 0x30

    The bootloader do nothing when this register has not the correct value.

    Are there any information about this register at address 0x01C14024.

    Thanks for you help and best regards
      Martin

  • 0 in reply to Martin Kaul
    TI__Guru* 83985 points

    Martin

    Is this other thread , the same issue?

    http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/64242/231437.aspx#231437

    Is there an easy way for you to convert the GEL file to the scripting required for Lauterbach tools, to provide us the full read out from the GEL file?

    If this is not possible, can you also read out the values at locations

    0x01C14008
    0x01C1400c
    0x01C14010
    0x01C14014

    and confirm that these are non-zero values.

    Also, can you confirm that on your custom board,  even if SATA and USB are not being used, the supply pins are all connected to PWR (1.2V) , for Rev 1.1 silicon. Can you confirm this?

    Normal 0 false false false MicrosoftInternetExplorer4

    Digital Supply

    Pin

    SATA_VDD

    M2

    SATA_VDD

    N4

    SATA_VDD

    P1

    SATA_VDD

    P2

    USB_CVDD

    M12

     

    Regards

    Mukul

     

  • 0 in reply to Mukul Bhatnagar
    Prodigy 110 points

    Hi Mukul,

    thanks for you reply.

    Is this other thread , the same issue?

    http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/64242/231437.aspx#231437

    yes this is the same issue. At begin my colleague thought that it is a problem with out flash content. But it seems more and more, that it is an problem of our custom board hardware...

    0x01C14008
    0x01C1400c
    0x01C14010
    0x01C14014

    All of these registers have a zero value.

    SATA_VDD Pin M2, N4, P1, P2 are all not connected

    USB_CVDD Pin M12 is connected to PWR (1.2V)

    Is this our problem?

    I can convert the GEL script to a Lauterbach script - but for today (German time) I leave off work. If you reply til tomorrow (German time) that the above information is not enought, then I convert the GEL script.

    If it is a hardware problem - is the problem solved when we change the OMAP-L138 to Revision 2.0?

    thanks a lot and best regards
      Martin

  • 0 in reply to Martin Kaul
    TI__Guru* 83985 points

    Martin Kaul said:
    Is this our problem?

    Yes, unfortunately with silicon revision 1.0 or 1.1 (in your case) you need these pins to be connected to power.

    Martin Kaul said:
    If it is a hardware problem - is the problem solved when we change the OMAP-L138 to Revision 2.0?

    Yes, if you have revision 2.0 silicon, you should not see any issue even these pins are not connected to power as in your current design.

    Martin Kaul said:
    I can convert the GEL script to a Lauterbach script - but for today (German time) I leave off work. If you reply til tomorrow (German time) that the above information is not enought, then I convert the GEL script.

    Likely not required since you did confirm that you are reading out zeros from all of the locations (including 0x24). The device will work fine in debugger mode, but it won't allow booting.

    Regards

    Mukul

  • 0 in reply to Mukul Bhatnagar
    Prodigy 110 points

    Hi Mukul,

    thanks a lot for your help. I forwarded this forum discussion to our hardware developers - I suppose that we change the silicon to Rev 2.0 and then test flash boot again...

    I checked the current OMAP-L138 errata sheet (SPRZ301c). I found the information/constraint not in the errata sheet. Is it possible to add it to the errata sheet so that it is detectable for others.

    best regards
      Martin

  • 0 in reply to Martin Kaul
    TI__Guru* 83985 points

    Hi Martin, Marc

    Martin Kaul said:
    thanks a lot for your help. I forwarded this forum discussion to our hardware developers - I suppose that we change the silicon to Rev 2.0 and then test flash boot again...

    Let us know how this goes. We expect rev 2.0 to get you past this issue.

    Martin Kaul said:
    I checked the current OMAP-L138 errata sheet (SPRZ301c). I found the information/constraint not in the errata sheet. Is it possible to add it to the errata sheet so that it is detectable for others.

    I will take this feedback and run it by the documentation team and let you know the plan w.r.t errata. FYI, it is being captured in the latest version of the datasheet (Table 3-33 , Pg 75) and the schematic checklist page (I have added a few more notes in bold)

    http://processors.wiki.ti.com/index.php/OMAP-L13x_/_C674x_/_AM1x_Schematic_Review_Checklist

    Regards

    Mukul

     

  • 0 in reply to Mukul Bhatnagar
    Prodigy 110 points

    Mukul Bhatnagar said:

    Hi Martin, Marc

    thanks a lot for your help. I forwarded this forum discussion to our hardware developers - I suppose that we change the silicon to Rev 2.0 and then test flash boot again...

    Let us know how this goes. We expect rev 2.0 to get you past this issue.

    [/quote]

    As assumed - with rev 2.0 of the silicon booting from flash works fine. We changed the OMAP on some of our boards to Rev 2.0 OMAP. After flashing the application starts directly from flash.

    Thanks a lot for your help - best regards
      Martin