• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 99 subscribers
  • Views 948 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.

DM648 UART BOOT MODE outputs BOOTER instead of BOOTME

Eddie3909
Guru 10385 points

Hi

We fired up our new board with BOOTME[3:0] set to 0011 and Hyperterm outputs BOOTER instead of BOOTME when we power up. I grepped the DM648 boot loader document and couldn't find BOOTER anywhere. It seems we have some other type of boot mode that since BOOTER is output and it cannot accept the AIS file (I checked for the magic words in the boot file and they were present). Also, it first outputs DATA CORRUPT when I send the AIS file and then it outputs BOOTME continually until the hyperterm file transfer is complete.

Below is the output when we send the AIS file.

BOOTER   DATA CORRUPT       BOOTME ...... BOOTME ...... BOOTME ...... BOOTME .
..... BOOTME ...... BOOTME ...... BOOTME ...... BOOTME ...... BOOTME ...... BOOT
ME ...... BOOTME ...... BOOTME .

The AIS file was created using

perl genAIS.pl -i Debug\UART_BOOT_Tester.out -o UART_Boot_Tester -otype txt -bootmode uart -crc 1

Any ideas, thoughts, ideas, corrections, comments...[8-|]

  • 0
    TI__Guru*** 125430 points

    After a failed boot connect with an emulator and open a memory window to address 0x0204900C (32-bit view).  That is the location of the BOOTCMPLT register.  Chapter 7 of the DM648 Bootloader App Note gives a list of failure codes that would be found in this register in the event of a failed boot.

  • 0 in reply to Brad Griffis
    Guru 10385 points

    Hi Brad

    Thanks for pointing me to that information.

    We tried a second board and it outputs BOOTME instead of BOOTER (Yeah!), but I still get a data corrupt error. (see below).

    BOOTME   (I start the TeraTerm transfer here) DATA CORRUPT       BOOTME ...... BOOTME ...... BOOTME ...... BOOTME ...
    ... BOOTME ...... BOOTME ...... BOOTME ...... BOOTME ...... BOOTME ...... BOOTME
     ...... BOOTME ...... BOOTME ...... BOOTME ...... BOOTME ...... BOOTME ...... BO
    OTME ...... BOOTME ...... BOOTME ...... BOOTME ...... BOOTME ...... BOOTME .....
    . BOOTME ...... BOOTME ...... BOOTME ...... BOOTME ...... BOOTME ...... BOOTME .
    ..... BOOTME ...... BOOTME

    Hyperterm also gives the same output. Should I be setting something different in my serial tools? (binary transfer? ? ?)[:S]

    Here is the memory where you suggested I look

    0x204900c     0x00000000    (BOOTCMPLT: does not indicate an error!)

    0x2049010     0x00000000

    0x2049014     0x019f0003    (BOOTMODE[3:0] = 0011 and FASTBOOT = 1)

    0x2049018     0x1b77a02f

    0x204901c     0x00080b23

    Here is the start of my AIS file.

    41504954585359035853590100A1F40000000200003C30F6006DC02A0000506A00000362003C36E60C6E2C6E00000000E4000000003C30F6006F102A0000506A00000362003C36E60C6E2C6E00

     

  • 0 in reply to Eddie3909
    TI__Guru*** 125430 points

    Well, crud!  That stumps me too.  I've notified the DM648 team of your issue and requested they respond on the forum.

  • 0
    TI__Genius 17355 points

    The BOOTER output indicates that the initial detected bootmode (as determined by the pins) was not UART boot, and that instead this UART boot is the result of a fallback. When you see the ...... BOOTME outputs, it means that the ROM boot loader has detected 500 errors and is trying to restart the boot process again.  The DATA CORRUPT output, followed by the BOOTME again, indicates that the initial magic word was received correctly but that there was then an error while trying to parse the AIS data.

    Please note that UART boot can be somewhat finicky since there is no back and forth negotiation.  You might want to try using teraterm and set a delay between each character sent.  Even better would be to have a host program that can appropriately set delays during different parts of the boot. and react if errors like the ones you see occur.

    Regards, Daniel

  • 0 in reply to Brad Griffis
    Guru 10385 points

    I created a routine to echo back the characters I send and it appears OK.

    Is there a SW tool you guys can recommend for sending the AIS file? Maybe Teraterm or Hyperterm are screwing up the transfer somehow.

    Cheers

  • 0 in reply to Eddie3909
    Guru 10385 points

    Yiks. I set the delay to 1 msec (the smallest delay Teraterm will let me use) and the download is INCREDIBLY slow. But at least now I get DONE. I think we will have to develope our own download app as you suggested.

    I can't believe that the DSP can't keep up to the serial transfer.

    Thanks

  • 0 in reply to Eddie3909
    Guru 10385 points

    Could it be that the 32 bit CRC is keeping the DSP to busy?

    I,m going to try the download without the crc and user zero delay.

    Cheers

  • 0 in reply to Eddie3909
    Guru 10385 points

    I tried two options to test my "DSP to busy with CRC" theory.

    echo CRC calculated for entire image.
    perl genAIS.pl -i Debug\UART_Boot_Tester.out -o UART_Boot_Tester  -otype txt -bootmode uart -crc 2

    echo No CRC
    perl genAIS.pl -i Debug\UART_Boot_Tester.out -o UART_Boot_Tester_no_crc  -otype txt -bootmode uart -crc 0

    When I use option "crc 2", the DSP UART bootloader does not return "DONE".

    When I use option "crc 0", the DSP UART bootloader does return "DONE" and my program runs.

    Success!

    The CRC is killing the download![*N]

     

     

  • 0 in reply to Eddie3909
    TI__Genius 17355 points

    Eddie,

    This is what I would expect to see.  The CRC calculations will require an amount of time that should be roughly linearly related to the size of the sections. This is why I indicated using a custom program would likely be necessary.  There are two ways to help alleviate the issue of trying to guess how long to wait if you want to use crc option 1.  One is to split sections into equal size subsections (for example, of 4K bytes each).  Note the perl utility does not do this and you would have to modify it. Another option (which I have tried successfully on another device) is to first download a small bit of code using a section load command that can provide some sort of feedback mechanism, and then call this using a JUMP command after every section.  What I have done was to download a small function that simply wrote "DONE" to the UART port.  At the end of every section load command, I would place the request CRC command, and immediately place a jump command to the UART DONE code I had loaded.  While the Request CRC command was processed, the JUMP command would enter into the UART FIFO and would be processed after the Request CRC was complete.  When the host sees the DONE statement, it knows it can continue with the next AIS command.

    Daniel

  • 0 in reply to Daniel Allred
    Guru 10385 points

    Hi Daniel

    Thanks for the information. It really helps.

    Could TI send us the code used "on another device", the modified perl, and the PC host app? We are really under the gun to get this out the door. It came as a surprise that the DSP can't keep up.

    I promise no support questions about the apps if you can send them to us!

    Cheers

  • 0 in reply to Eddie3909
    TI__Genius 17355 points

    Eddie,

    I no longer have this code handy, but if I do come across it, I will let you know.

    Regards,

    Daniel