TMS320C6657: UART Boot mode problems

Is there going to be a response to this from the factory?

David,

this issue is currently assigned to me. However, I have not been able to get to this due to existing priority of issues. I am probably going to be able to look into this only towards the end of this week at the earliest.

In the mean time, if you would provide some information regarding your board and the boot setup, I can try to figure out if anythings jumps at me.

1. Have you tested this on TI EVM which is known good hardware or does this occur only on your board.
2. Can you try to load your code sections in MSMC memory only with entry point at 0x0c000000 and check to see if this makes a difference.
3. Please share the binaries and the map file for the application for us to see where the load sections. also list the steps and tools used to generate the UART binary.
4. When the boot fails and you connect to the DSP, is the Program counter still in ROM or is it in MSMC/L2 RAM region. If it is sstill in ROM memory, can you please provide the value of the Program counter so we can corelate it with symbols in the boot ROM.


Regards,
Rahul

1.   Have not tested on our EVM.   We feel confident that our custom 6657 circuit board is working adequately for a UART boot process.  As noted in my original post, the ROM boot loader is completely reading in our entire boot image file, with all XMODEM Acknowledgements appearing as described in T.I. literature.

2.   The Test program is designed for MSMC.   If you examine my first post carefully, you'll see a section header at file location 0xC0 with segement length = 0x07A0 and load address  = 0x0C00C000.   This is the program's .text segment.     the only other load segment is a the start of the boot image, a CINIT section that is  0xA0 bytes in length, located at L2 SRAM 0x00804000.

3.  Attaching archive (.zip) of files   

                BootTest_A.hex  (Boot table from Hex6x.exe) 

                  BootTest_A.map   

                  BootTest_A.dat     (binary implementation of boot table file BootTest_A.hex) ,

                 BootTest_AXmodem.bin

        Steps to generate the UART Binary:

         A)  Modified  BConvert64x  (source provided in PDK) to build in Visual Studio 2015 C++.   

                       Changes:  Fixed issues with file access APIs allowed in Win10.   

                                        Output the bit stream into a Binary File, rather than an ASCII file.

                                        Verified the binary was identical to the  _.hex

         B)  We have a Python utility that was used to wrap the  BootTest_A.dat into the Xmodem format

         C)  We are loading the UART image over a USB link into a Cypress USB Bridge processor, which converts the stream to UART 115.6K.   Scope traces in first postingvalidates this is working.

4)  Will check on that execution address & state of processor at moment we connect JTAG (non-program loading) and post result later today.

                                         BootTest_AXmodem.zip

The final one (4):    PC is at  0x20B11B54   (in the ROM boot load space)

-Dave

Slightly more reverse engineering detail...   After reading in our Boot image, the ROM Boot loader execution locale is confined as:

0x20B0 2E88

    -->  Branches(calls)  0x20B1 1B34

          Returns from 0x20B1 1B56   to    0x20B0 2EA0

          Returns from 0x20B0 2EA6   to  0x20B0 2E88

-Dave

David,

Thanks for the information. I did a quick review of the files.

The maap file you have provided is from the HEX tool and not the one corresponding to your application .out so it doesn`t tell us where all the symbols and code/data sections are loaded.  The way we test XMODEM transfer is to use a windows Serial Terminal utility and send the binary file to the DSP so we don`t wrap the binary in any XMODEM format as your mentioned.

I am providing a example binary that we used in the past to test UART boot on this device using one of our internal boards.

C6657_UART_boot.zip

the Steps to create the image were :

• hex6x -a -order=$(ORD) -boot -e=_c_int00 -bootorg=0x0400 -memwidth32 -romwidth32 -o=tmp.btbl <application.out>
• b2ccs tmp.btbl application.btbl.ccs
• byteswapccs  application.btbl.ccs application.btbl.swap.ccs
• ccss2bin application.btbl.swap.ccs application.btbl.swap.bin

the device was then configured to boot in UART boot mode with a serial terminal connected to UART0 on the SOC at 115.2 kbps. The tools was used as described here to send the boot image to the SOC.

processors.wiki.ti.com/.../KeystoneII_Boot_Examples

Regards,

Rahul

Here is the Linker's  .map file for that project.

We will review carefully the steps you mention, which seem familiar from past posts on this forum.  

However, those back end utilities are not present as executable programs in our recently installed CC7 & SDK for Windows.  We DO find C sources for these utilities in the PDK's for these utilities.  Building these C programs in a Windows environment with VS 2015 C++ generates errors due to the deprecation of the File-API's being used, so that has to be corrected in each of them.   

Am I missing something?   My perception is that these back-end processing steps are not explained in the literature (neither 6657 Data sheet nor Keystone Boot loader guide)?  

-Dave

BootTest_A_Map.zip

Spent another day experimenting.  

1)  The built .bin image you sent me for UART booting of 6657 booted properly into my EVM using TeraTerm. 

     To do this, the below pictured EVM switch configurations were necessary:

                 Key lesson here:    SW3:1:  is set for Big Endian.

Findings:

    Under no conditions did the C6657 ROM boot loader copy any data into any C6657 memory if Switch 3:1 is in Little Endian OFF position.  The boot loader seems to read in the full binary boot table with XMODEM exchanges, but merely discards the data. The ROM B/L will end up "stuck" in a loop encapsulated by the ROM BL address locations mentioned higher up in this post. 

This was found to be true with any boot image I generated, with the boot image T.I. provided me, and with a small hand-coded (ie. very simple) binary boot table I made.  Permutations such as reversing byte-ordering of section headers made no difference.  The deterministic behavior: 

    Power on Endian-ness = BIG (SW3:1 ON)-            Boot image data is always found in C6657 memory after XMODEM transfer (even if endian-ness in image is wrong)

                                            LITTLE (SW3:1 OFF)      C6657 memory is "un touched" after XMODEM transfer & RBL is still executing in a loop. 

Hypothesis:

    To use UART boot mode, the chip has to be configured for Big Endian. 

    That means for booted firmware to work, it must be compiled for Big Endian ALU operation.

Supporting Test:

    We rebuilt our boot test program in Big Endian setting for CCSv7.   

Provided command line to hex6x:

                 hex6x  -boot -a -e=_c_int00 -order=M -memwidth=32 -romwidth=32 -oBootTest_A.hex -mapBootTest_A.map   BootTest_A.out

Convert to Binary:

      Using the BConvert64 utility which was modified in VS2015C++ complier to output only binary, applying  -be  flag.

                 bConvert64       BootTest_A.hex   BootTest_A.dat    -be     // Modified BConvert64.   Writes to a binary file, rather than ASCII file

UART send to 6657:

   Tera Term XMODEM transfer.  of  .dat file to EVM through the USB Virtual Comm associated with the XDS100 mini USB .

Verified:
   Connected debug with no program load or GEL load.

I'm sure this will work on our custom board too once we re-wire to set the GPIO[0]  ENDIAN to be BIG.

Conclusion: 

 Without being able to look at source code of T.I.'s ROM B/L, I'm pretty confident the above assertions are true.