• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 379 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.

OMAP3503 bootloader flashing issue

Vini
Intellectual 895 points
Other Parts Discussed in Thread: OMAP3503

Hi All,

I am having a problem with my OMAP3503 based board. I am not able to flash the bootloader using EVMFlash tool. A popup saying "Failed to connect to the traget" is shown. The details are given below:

The booting sequence is SYS_BOOT[5:0] = 0b101111 i.e. USB -> UART3 -> MMC1 -> NAND

When I try to flash bootloader using UART3, the loading fails giving an error message "Dl connect operation failed. Error code: 0xFFFFFFFD"

The log is attached ("evmflash_uart_log.txt" file).

2021.evmflash_uart_log.txt

Same error mesage is shown when I try to boot using USB. The log is attached ("evmflash_usb_log.txt" file).

6560.evmflash_usb_log.txt

Can anyone tell what can be the reason for this?

  • 0
    Intellectual 895 points

    Hi All,

    Some additional information...

    After debugging through JTAG, the tracing vector values are noted down as given below:

    While trying to flash using UART, 0x4020FFBC = 0x0007307F and 0x4020FFC0 = 001E0044

    As per my understanding, the tracing vector bits 14 and 15 show that booting message and image are not received by OMAP.

    When should OMAP BOOT ROM code set these bits? And what can be the reason that these bits are not set?

    As per the log attached with last post, the log message "Second file transferred to target (0x5704 bytes)" indicates that EVMFlash tool sends some file to OMAP. But as per tracing vector, OMAP has not received any booting mesage or image. What can be the reason for that?

    Even more interseting observation is that while trying to flash using USB, 0x4020FFBC = 0x00000000 and 0x4020FFC0 = 00000000 which doesn't make any sense to me.

    Have anyone else noticed this behaviour with OMAP3503?

    I am using OMAP3503 CBC package.

    Vini

  • 0 in reply to Vini
    TI__Intellectual 1665 points

    Vini,

    Please try to use our new flashing tool, it can be downloaded from https://gforge.ti.com/gf/project/flash. The user guide is at http://processors.wiki.ti.com/index.php/Flash_v1.0_User_Guide

     

    BR, Punya

    ---------------------------------------------------------------------------------------------------------

    Please click the Verify Answer button on this post if it answers your question.
    ---------------------------------------------------------------------------------------------------------

  • 0 in reply to Punya Prakash
    Intellectual 895 points

    Hi,

    We have a doubt that DDR is not soldered properly. While trying to test DDR though JTAG, the test failed. Some lines seem to stuck LOW permanently.

    Now the question that I have is whether the DDR is used while flashing or not? And if yes, at what stage it comes into picture?

    I am under the impression that a small code is copied by EVMFlash tool to the internal SRAM of OMAP and this code is executed from SRAM to copy the boot image to NAND.

    Can anyone from TI clarify how it works? Can the error code that I am getting be due to the DDR?

    Vini

  • 0 in reply to Vini
    TI__Intellectual 1585 points

    Vini -

     

    With EVMFlash or the new flash tool mentioned by Punya, DDR is used during the programming process.  Specifically, the program downloads some code to the target DDR known as the "2nd loader".  Then the host side tool communicates with the second loader to perform the actual flashing process.  If you are experiencing DDR problems, i am not surprised to hear that your EVMFlash is not working.

     

    Greg

  • 0 in reply to Greg Guyotte
    Intellectual 895 points

    Thanks Greg

    This seems to make sense now. I will send boards for re-heating and will update you guys later.

    Vini

  • 0 in reply to Greg Guyotte
    Genius 3685 points

    Hi Greg,

    Unless you have changed naming conventions recently (which I think not :-) I have a minor correction to you reply. The 2nd downloader is what's download to internal memory by help of the ROM-code using a peripheral boot. Then this 2nd downloader downloads the flash-driver (for nand/nor/(e)mmc/ram/etc) to Internal or External memory dependent on platform/chip/configuration. You might therefore have a system where all code is running in internal memory...

    The above being said the heap (which is used for storing link-layer communication packages sent from/to the PC) is located in external memory on all platforms, which would make the process fail in case this isn't working => You point, that you need working external DDR-memory for flashing to succeed is still valid :-)

    I hope this post clarified more than confused :-) - Best regards
      Søren