• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 2 answers
  • Subscribers 99 subscribers
  • Views 593 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.

OMAP-L138: Boot flash issue

Toan Tran2
Prodigy 80 points
Part Number: OMAP-L138
Other Parts Discussed in Thread: OMAPL138

Hi All,

I have a problem with OMAPL138, Maybe someone help me!!!

I am using OMAP l138 in my project,

The flash using to stores bootloader, os and some datas.

Bootloader is secondary bootloader.

The bootloader run quite good for along time in many boards.

The issues is occur in some board: After boot up succees, I restart, it cannot boot again.

I have been try: Using sft to load bootloader in flash, store to file in PC, then re program this data again to flash. It can boot normally.

This issue happen randomly on random board.

We are confuse with this issue: i do not known hardware issue or software issue? 

Could you help me fix this issue? Thank a lot,

Best regards,

Toan 

  • 0
    TI__Guru** 101910 points

    Hello Toan,

    What version of software are you using?

    Please include more information about exact steps to replicate and any terminal output that may be helpful.

    Regards,

    Nick

  • 0
    TI__Guru** 116170 points

    Toan,

    The failure to boot issue can happen due to many reasons such as 

    1. Pull up/Pull down on the boot pins

    2. Power up sequence not starting the device correctly

    3. Interface to flash is not working as expected during boot

    4. Device is boot from ROM but is hung in secondary boot or application 

    The only way to understand this issue is to connect to the device when it fails to boot and check where the ARM core Program counter. If the Program counter is in ROM, then report back on the E2E forum with PC value and we can tell you why it may have failed. If the failure occurs post ROM boot, you will need to check SBL/app to see why it fails. 

    The fact that it happens only on some boards indicates , it is less likely to be a software issue and more likely to be associated with power up sequence, flash interface or boot pins.

    We provide a debug GEL for this device, that allows you to capture boot and SOC status for analysis. It is included in latest CCS  but if you don`t have it, I am attaching it here:

    1464.OMAPL1x_debug.gel

    Usage for this is described in the application notes here:

    https://www.ti.com/lit/an/spracm8a/spracm8a.pdf (Chapter 4)

    Please post the log in a text file to E2E for our analysis. Hope this helps. 

  • 0 in reply to Rahul Prabhu
    Prodigy 80 points

    Dear Rahul Prabhu,

    The Omap we are using is secure Omap. Can I check ROM boot status when the issue happen. And does ROM boot version in our Omap chip can debug with method you share?

    The not understandable is why I using sft to load bootloader in flash then reprogram itself, I can boot again?

    I will try to find what status of ROM boot.

    Thanks,

    Toan

  • 0 in reply to Nick Saulnier
    Prodigy 80 points

    Dear Nick Saulnier,

    We have been modify bootloader project, using NAND16 bit. Which software you mentioned will help to debug? 

    Thanks,

    Toan

  • 0 in reply to Rahul Prabhu
    Prodigy 80 points

    Hi,

    Good news:

    My bootloader is about 565 kb, stay in block 1 to 5

    I have detected issue: when I using sft check block status, I found that when read data in page 58 in block 1 is return status NAND_STATUS_READ_ECC_ERROR_CORRECTED. 

    I try to correct ecc in this page, now my board can boot normaly.

    The sft Nand driver will correct data with ecc information. I don't know rom boot will use it or not.

    Can you give me the suggestion about my issue and how to prevent this issue happen. We're create high-end product, and this is very critical case for our customer.

    Thanks,

    Toan

  • 0 in reply to Toan Tran2
    TI__Guru** 116170 points

    Please note that the ROM bootloader will use NAND ECC data when booting. The ECC data needs to be in correct format for the ROM to boot successfully from NAND. 

    Whether an error occurs in a NAND block or page is not dependent on OMAPL138 but the NAND technology itself so why the error occurs in the page may be explained by the raw NAND vendor. The EMIF only provides mechanism to correct upto 4 bit error in 512 bytes of the NAND data.

    One thing to note is that most NAND manufacturers will require you to erase the NAND page/block before programming it so all the data is marked 0xFF or 0xFFFF before the NAND page is programmed. Can you confirm that you are performing a NAND block erase and the block is not marked as bad.

    Are you seeing this behavior on all the boards or are only some boards showing this behavior.

    Regards,

    Rahul 

    PS: If possible also indicate the part number of the NAND in use for us  to check for compatibility issues with device ROM. Details of supported NAND are provided here:

     (Appendix B)

  • 0 in reply to Rahul Prabhu
    Prodigy 80 points

    Dear Rahul Prabhu,

    Were are using MT29F4G16ABBDAH4-IT_D. Please help me to check.

    Note: the block will be erase before write data, then all data in block will be marked 0xFF.

    Thanks,
    Toan

  • 0 in reply to Toan Tran2
    TI__Guru** 116170 points

    Toan,

    The NAND device that you are using is compatible with the OMAPL138 device as it is ONFI 1.0 compatible with 2K Pages with 4 bit ECC requirement.

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Prodigy 80 points

    Hi Rahul,

    We have been detected the issue is quality of Nand not good. Too many bad block in Nand, so RBL cannot boot normaly.

    Thanks for your useful support.

    Best regards,

    Toan