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

DM8148 boot XIP issue

Arnaud Boursier
Prodigy 125 points


Hi.


We have designed yet another board based on DM8148 and are having some random trouble when booting from NOR Flash (XIP)

We had already designed several systems based on DM8148 in the past years but none yet using XIP boot mode. On a few boards, booting from NOR Flash in XIP mode sometimes crashes.

The boards crashing during XIP boot from NOR Flash never crash when they boot from SD nor do they crash afterwards when booting from NOR passed properly.

We used the JTAG debugger to execute step by step. The code starts executing the first instructions from NOR Flash but at some early point, the address pointer jumps to some unexpected address and of course the codes stops executing properly. This always happen at the same point for a given binary code but if we make any change and recompile code, the crash happens somewhere else, yet, always at the same point.

While probing NOR Flash CS, I noticed that, when the execution crashes, the CS length is a bit shorter than when the code executes properly (about 108ns instead of 120ns). This makes me think that the problem may be caused by a PLL not initialized properly, generating an instable and too fast internal clock applied to the processor core, making the code execution to crash very quickly.

Again, this problem never happens when booting the same processor board from SD. During SD boot, there are some NOR flash accesses and those always show a 120ns CS length.

I think DM8148 initializes clocks (or something else) differently when this initialization is done by the ROM boot code (SD boot mode) than what our own boot code does from the Flash (XIP) but we could not find any detail about what and how the DM8148 ROM boot code initializes so, it's hard to compare with our own first level boot in XIP mode.

Is my description of our problem clear enough? Has anyone ever experienced similar issue and is there any know issue and workaround associated?

Thanks.


Arnaud.

  • 0
    TI__Guru**** 170625 points
    Moving this post in DM814x e2e forum.

    BR
    Pavel
  • 0 in reply to Pavel Botev
    Prodigy 125 points
    I'll be happy to promote the solution by marking the question as answered...
    Sorry if I posted in the wrong forum. Thanks for the relocation.
  • 0
    TI__Guru**** 170625 points
    Arnaud,

    This looks like HW design malfunction to me. Can you try with the HW diagnostic test for NOR Flash, available at Mistral website? This CCS test id for the DM814x TI EVM, so you might need to adjust it for your custom board.

    www.mistralsolutions.com/.../support-downloads
    Diagnostics Software -> Expansion I/O Board -> Rev D -> IO EXPANSION BOARD Rev D -> src -> CCS_Test_Code -> IOExpansion_Application -> NOR_Flash

    This CCS test application validates the NOR-Flash for its ability to perform write access read access and data storing ability. The test application first erases the sectors to be written, writes a known pattern into the desired number of sectors and then reads back the same.
    If the data read does not match the expected pattern, this test is declared failed. It is declared pass otherwise.

    See also if the below wiki pages will be in help:
    processors.wiki.ti.com/.../DM814x_Hardware_Design_Guide
    processors.wiki.ti.com/.../_C6A814x_Schematic_Review_Checklist
    processors.wiki.ti.com/.../Understanding_u-boot-min_startup_for_DM814x
    processors.wiki.ti.com/.../Debug_Tips_for_DM81xx_Boot_Fail
    processors.wiki.ti.com/.../AM335x_board_bringup_tips

    Regards,
    Pavel
  • 0
    TI__Guru**** 170625 points

    Arnaud Boursier said:
    This makes me think that the problem may be caused by a PLL not initialized properly, generating an instable and too fast internal clock applied to the processor core, making the code execution to crash very quickly.

    Can you provide me your PLL registers settings?

    Arnaud Boursier said:
    I think DM8148 initializes clocks (or something else) differently when this initialization is done by the ROM boot code (SD boot mode) than what our own boot code does from the Flash (XIP) but we could not find any detail about what and how the DM8148 ROM boot code initializes so, it's hard to compare with our own first level boot in XIP mode.

    Regarding DM8148 ROM Code in NOR/XIP boot mode, see TRM, 4.7.1 Overview, 4.7.2 XIP Memory

    Regards,
    Pavel

  • 0 in reply to Pavel Botev
    Prodigy 125 points
    Hi Pavel.

    Thanks for your quick reply.
    We have already extensively tested the Flash access from the DM8148 by running erase, write and read tests. We have excluded the hardware issue there... We have designed several DM8148-based systems and are now perfectly aware of the hardware traps to avoid.

    It appears that when the DM8148 does crash during boot, the Flash is properly read (checked with JTAG debugger) but that at some time the program counter jumps to unexpected address while it is not supposed to jump anywhere else than to next instruction.
    As I mentionned, it also appears that when this unexpected jump happens, the processor core seems to be running a bit too quickly which makes me think that the root cause is not a problem with Flash access but with PLL initialization.
    After a reset, the clock frequency (checked indirectly through Flash CS duration measurement) may return to its expected frequency in which case the code is executed properly.
    This never happens when booting from SD card which goes through internal boot ROM code execution while XIP does not. So my question is what does internal boot do that is not done in our own XIP first level boot code that affects the clock functionning?..

    Thanks for pointing to some wiki articles. I will take a closer look especially at the ones dealing with boot.

    Arnaud.
  • 0 in reply to Arnaud Boursier
    TI__Guru**** 170625 points

    Arnaud,

    Arnaud Boursier said:
    We have excluded the hardware issue there

    Then how it is possible one SW to run correctly on one piece of HW, and the same SW to fail on other HW?

    Arnaud Boursier said:
    but that at some time the program counter jumps to unexpected address while it is not supposed to jump anywhere else than to next instruction.

    Check the temperature here, there might be overheating.

    Arnaud Boursier said:
    As I mentionned, it also appears that when this unexpected jump happens, the processor core seems to be running a bit too quickly which makes me think that the root cause is not a problem with Flash access but with PLL initialization.

    Please provide me your PLL registers settings. Also, are you using EZSDK or DVR RDK or else? Which version?

    Arnaud Boursier said:
    This never happens when booting from SD card which goes through internal boot ROM code execution while XIP does not. So my question is what does internal boot do that is not done in our own XIP first level boot code that affects the clock functionning?

    Again, the difference between the XIP/NOR ROM Code and MMC/SD ROM code can be found in the DM814x TRM, chapter 4 ROM Code Memory and Peripheral Booting. Also the below wiki page might be in help:

    http://processors.wiki.ti.com/index.php/DM81xx_NOR_APPLICATION_NOTES



    Regards,
    Pavel

  • 0 in reply to Pavel Botev
    Prodigy 125 points

    Finally, the problem has been solved. It was simply a transitional too fast timing setting of the GPMC to access the Flash. During boot, at some time, the GPMC timings were temporarily set to too short access time, then set anew to longer access timings, compatible with the Flash requirements. During the short period where the GPMC was too fast, it sometimes read wrong data which obviously crashed the processor...

    Very simple software mistake but quite tricky to locate.


    Thanks for your help, Pavel.