TMS320C6747 - OMAP-L137 UART Boot Host. Ver. 1.01 Problem

Mike, start with the debug GEL file to make sure you are in the correct UART boot mode and that there are no ROM error messages:

http://processors.wiki.ti.com/index.php/OMAP-L1x_Debug_Gel_Files

If it seems correct, then you might have a board connectivity problem on the UART_TXD pin. Try probing it as close to the device as possible to make sure it is toggling right after reset and go from there.

Jeff

Mike,

I have been booting the C6747 from UART2 for a while.  it works fine but see my post in the DSP/BIOS forum about communicating with the UART after the DSP has booted (i.e. if you use the PSP it does not set the UART speed correctly).  If you are not seeing BOOTME but strange characters then your UART speed may be incorrect.  Is your processor 300 MHz?   Also use the pin multiplexing tool to make sure your UART1 is enabled.  i.e PinMUX11 is 0x00001100

Regards,

Fawad

Jeff,

Thanks for the tip about the debug GEL file.  I've run it and everything looks okay.  The dump is at the end of this posting. 

With regards to a board connectivity problem, we are able to talk to the chip via UART1 on our board from a little utility program that we have after our application image is loaded into SPI flash with a CCS application.  From that perspective, it appears that the wiring on our board is correct between the DSP's UART1 and our board's UART output pins.

We have put a scope on the pins of the board connection to the DSP's UART1 to try and catch the BOOTME character string.  On our board, we do not see any activity on the UART1_TXD line.  This is in contrast to the EVM board on which we can see BOOTME on UART2_TXD line. 

At this point, we have confirmed:

1) The board connectivity from the DSP's UART 1 to our board's connector works.

2) The DSP is booting up in UART1 mode (see below)

3) We are not seeing BOOTME activity on the Tx line.

If you've got any more suggestions, I'm all ears.  I'm an application level software guy so this low level stuff is kind of new to me.

Thanks again and the GEL dump follows.

Mike

 

 

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

|             Device Information            |

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

DEV_INFO_00 = 0x9B7DF02F

DEV_INFO_01 = 0x00000000

DEV_INFO_02 = 0x0000F3FB

DEV_INFO_03 = 0x00000002

DEV_INFO_04 = 0x00000000

DEV_INFO_05 = 0x000003E0

DEV_INFO_06 = 0x00000080

DEV_INFO_07-DEV_INFO_08-DEV_INFO_09-DEV_INFO_10-DEV_INFO_11-DEV_INFO_12 = 8-0-151287-7-47-25

DEV_INFO_13,DEV_INFO_14,DEV_INFO_15,DEV_INFO_16 = 0,1,0,5442

-----

DEV_INFO_17 = 0x00030003

DEV_INFO_18 = 0x00000000

DEV_INFO_19 = 00000

-----

DEV_INFO_20 = 0x30303864

DEV_INFO_21 = 0x3330306B

DEV_INFO_22 = 0x00000000

DEV_INFO_23 = 0x00000000

-----

DEV_INFO_24 = 0x0701902F

DEV_INFO_25 = 0x08024EF7

DEV_INFO_06 = 0x00000080

DEV_INFO_26 = 0x2A840020

 

 

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

|               BOOTROM Info                |

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

ROM ID: d800k003

Silicon Revision 2.0

Boot Mode: UART1

 

ROM Status Code: 0x00000000

Description: No error

 

Program Counter (PC) = 0x007F5D34

 

 

Fawad,

Thanks for your posting but our problem is that we do not see any characters sent on the UART 1 TX line during the execution of the ROM based code.  This code should send out the BOOTME sequence but we are not seeing it.  We are looking at it with a scope to avoid the baud rate issues that you've mentioned in your posting and we simply don't see the line changing voltage levels at all.

Thanks for your help.

Mike

Mike,

I am actually using a OMAP L-137 board rather than a C6747 at the moment.  The L-137 has a C6747 in it.  When I changed the boot to UART1 and looked at the TX line I saw data on the UART1 TX line which looks just like BOOTME.  I did not feed it into my RS-232 terminal to check but saw it on the scope.  Unless there is something wrong with the bootloader the TX line will produce BOOTME as soon as the DSP starts up.  So my guess is a short on the TX line.

Regards,

Fawad

Fawad,

Thanks for the information.  We are working with our own board.  I'll check the TX line again for shorts.

Do you know if all of the Boot pins not listed in the Boot Mode Selection Table (Appendix A of SPRABB1B) need to be pulled up to 3.3 V through 20K pull-up resistors as is the case on the Spectrum Digital Evaluation board?  Specifically, boot pins 8 and 11.

Thanks again for the help.

Mike

Jeff,

On our board, we are not pulling up Boot Pins 8 and 11 (TMS320C6747 DSP pins R3 and A4 respectively) to 3.3V through 20K resistors the same way that the Spectrum Digital OMAP-L137 EVM does.  Can you tell me if those pins need to be pulled up to 3.3V?

Thanks,

Mike

Mike,

The data sheet says no.  My own board is not here yet but from the schematics Boot pins 8 and 11 are not used on my board.  Can you check the voltages on the pull up resistors to confirm you do get the right levels during power-up?  A power-up issue maybe?  The C6747 needs voltages to come up in a very specific order.

Regards,

Fawad

No those pins are not used by the boot loader so you do not need to pull them up.

From the program counter, I can tell that the boot loader is polling in the UART receive loop. Can you use the UART Boot Host utility and try to load an AIS image to the DSP and see if that works (with "Wait for BOOTME" unchecked)?

Jeff

Hi Jeff,

I did a short series of tests.

TEST 1 - Loaded the GEL file with the FTDI TTL-232R USB to TTL Serial Cable connected between the Host PC and the UART 1 header on our board.  Connected CCS to the DSP.  The PC got to 0x00712144 which is less than the previous value so I was concerned that it did not get as far and repeated the test without the cable.

TEST 2 - Loaded the GEL file without the FTDI TTL-232R cable.  Connected CCS to the DSP.  The PC got to 0x007F5D68 which is closer to what it was previously.

TEST 3 - Reconnected the FTDI TTL-232R cable from our host to the UART1 header on the board.  Connected CCS to the DSP.  The PC got to 0x007F5D6C which is similar to the previous valud and the TEST 2 value.

TEST 4 - Powered up the board with the FTDI TTL-232R cable attached.  Started UART Boot Host, Unchecked "Wait for BOOTME".  Browsed for the image on the host hard drive and chose COM8.  Got a "(Serial Port) Read Error!".  Brought up CCS 3.3.  Loaded the OMAP Debug GEL file.  Attempted Debug | Connect and got an error indicating that the target did not have power.  The board is powered up.

The dumps for each of these tests is given below.  Thanks again for the help.

Mike

 

 

TEST 1 - Loaded the GEL file with the FTDI TTL-232R USB to TTL Serial Cable connected between the Host PC and the UART 1 header 

 

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

|             Device Information            |

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

DEV_INFO_00 = 0x9B7DF02F

DEV_INFO_01 = 0x00000000

DEV_INFO_02 = 0x0000F3F3

DEV_INFO_03 = 0x00000002

DEV_INFO_04 = 0x00000000

DEV_INFO_05 = 0x000003E0

DEV_INFO_06 = 0x00000080

DEV_INFO_07-DEV_INFO_08-DEV_INFO_09-DEV_INFO_10-DEV_INFO_11-DEV_INFO_12 = 8-0-151287-7-47-25

DEV_INFO_13,DEV_INFO_14,DEV_INFO_15,DEV_INFO_16 = 0,1,0,5442

-----

DEV_INFO_17 = 0x00030003

DEV_INFO_18 = 0x00000000

DEV_INFO_19 = 00000

-----

DEV_INFO_20 = 0x30303864

DEV_INFO_21 = 0x3330306B

DEV_INFO_22 = 0x00000000

DEV_INFO_23 = 0x00000000

-----

DEV_INFO_24 = 0x0701902F

DEV_INFO_25 = 0x08024EF7

DEV_INFO_06 = 0x00000080

DEV_INFO_26 = 0x2A840020

 

 

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

|               BOOTROM Info                |

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

ROM ID: d800k003

Silicon Revision 2.0

Boot Mode: UART0

 

ROM Status Code: 0x00000018

Description: UART Frame Error

 

Program Counter (PC) = 0x00712144

TEST 2 - Load GEL without the FTDI USB TO UART cable.

 

 

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

|             Device Information            |

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

DEV_INFO_00 = 0x9B7DF02F

DEV_INFO_01 = 0x00000000

DEV_INFO_02 = 0x0000F3FB

DEV_INFO_03 = 0x00000002

DEV_INFO_04 = 0x00000000

DEV_INFO_05 = 0x000003E0

DEV_INFO_06 = 0x00000080

DEV_INFO_07-DEV_INFO_08-DEV_INFO_09-DEV_INFO_10-DEV_INFO_11-DEV_INFO_12 = 8-0-151287-7-47-25

DEV_INFO_13,DEV_INFO_14,DEV_INFO_15,DEV_INFO_16 = 0,1,0,5442

-----

DEV_INFO_17 = 0x00030003

DEV_INFO_18 = 0x00000000

DEV_INFO_19 = 00000

-----

DEV_INFO_20 = 0x30303864

DEV_INFO_21 = 0x3330306B

DEV_INFO_22 = 0x00000000

DEV_INFO_23 = 0x00000000

-----

DEV_INFO_24 = 0x0701902F

DEV_INFO_25 = 0x08024EF7

DEV_INFO_06 = 0x00000080

DEV_INFO_26 = 0x2A840020

 

 

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

|               BOOTROM Info                |

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

ROM ID: d800k003

Silicon Revision 2.0

Boot Mode: UART1

 

ROM Status Code: 0x00000000

Description: No error

 

Program Counter (PC) = 0x007F5D68

 

TEST 3 - Reconnected the FTDI TTL-232R cable from our host to the UART1 header on the board.  

 

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

|             Device Information            |

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

DEV_INFO_00 = 0x9B7DF02F

DEV_INFO_01 = 0x00000000

DEV_INFO_02 = 0x0000F3F3

DEV_INFO_03 = 0x00000002

DEV_INFO_04 = 0x00000000

DEV_INFO_05 = 0x000003E0

DEV_INFO_06 = 0x00000080

DEV_INFO_07-DEV_INFO_08-DEV_INFO_09-DEV_INFO_10-DEV_INFO_11-DEV_INFO_12 = 8-0-151287-7-47-25

DEV_INFO_13,DEV_INFO_14,DEV_INFO_15,DEV_INFO_16 = 0,1,0,5442

-----

DEV_INFO_17 = 0x00030003

DEV_INFO_18 = 0x00000000

DEV_INFO_19 = 00000

-----

DEV_INFO_20 = 0x30303864

DEV_INFO_21 = 0x3330306B

DEV_INFO_22 = 0x00000000

DEV_INFO_23 = 0x00000000

-----

DEV_INFO_24 = 0x0701902F

DEV_INFO_25 = 0x08024EF7

DEV_INFO_06 = 0x00000080

DEV_INFO_26 = 0x2A840020

 

 

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

|               BOOTROM Info                |

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

ROM ID: d800k003

Silicon Revision 2.0

Boot Mode: UART0

 

ROM Status Code: 0x00000000

Description: No error

 

Program Counter (PC) = 0x007F5D6C

 

 

 

TEST 4 - Powered up the board.  Attempted to bring up UART Boot Host with "Wait for BOOTME" unchecked.  CCS not connected.

 

(File IO): Read 168072 bytes from file C:\Temp\IPL_ACB_DSP_Release_2_0_1UART1.bin.

(Serial Port): Opening COM8 at 115200 baud...

(AIS Parse): Read magic word 0x41504954.

(AIS Parse): Performing Start-Word Sync...

(Serial Port): Read error! (The operation has timed out.)

(AIS Parse): I/O Error in read!

(AIS Parse): Boot aborted.

(Serial Port): Closing COM8.

 

 

Attempted to bring up CCS. 

Loaded the OMAP Debug GEL File.

Attempted to Connect and got an error.

 

 

Error connecting to the target:

Error 0x80002240/-180

Fatal Error during: Initialization, OCS, Control,

This error was generated by TI's USCIF driver.

 

SC_ERR_CTL_NO_TRG_POWER <-180>

The controller has detected a target power loss.

The user must turn-on or connect the power supply for the target.

 

 

 

Board Name: C6747_SDXDS560R

Cpu Name: ICEPICK_C_0

 

Abort:                       Close Code Composer Studio.

Retry:                       Try to connect to the target again.

Cancel:                    Remain disconnected from the target

Diagnostic:              Run diagnostic utility.

 

 

 

 

 

 

It looks like you are seeing very flaky behavior when booting from UART. Can you confirm that when booting from SPI flash there are never any issues?

For each test, are you power cycling the board or are you just toggling the reset pin? If possible, boot from the SPI flash to the state where you are able to communicate via UART with the device. Then change the boot pins to UART boot mode and do a warm reset. Do you see any BOOTME activity then? Remember to disconnect the JTAG cable when changing boot modes with warm reset, or the new boot mode will not be latched.

Otherwise you may have power or clock issues. Can you check the voltage levels for the core and IO supplies, as well as the input clock to the device?

Jeff

Hey Jeff,

Thanks again.  I've run the tests that you suggested and the results are as follows:

TEST 1: Booting from SPI Flash is not a problem.  I did it a dozen times without issue.

 

TEST 2:

Booted system from SPI Flash.

Connected our external DSP Monitor application via UART1 to the DSP.  This application runs at 57600 baud.

Passed a few messages and got  the correct responses.

Shut down the DSP Monitor application.

Changed the Boot Mode DIP switch from 01100 (SPI 1 Flash) to 10111 (for UART1).

Started the UART Boot Host application.

Set up the file and COM port settings in UART Boot Host without hitting Start. 

“Wait for BOOTME” is checked.

Pressed down the soft reset button on our board.

At the same time, I released the soft reset button and clicked on the UART Boot Host Start button.  There is about a 2 second delay after the soft reset button is released before the CPU and FPGA on the board release the DSP’s reset line.  (I tried different sequences in terms of releasing the board reset and starting the UART Boot Host but the results were always the same).

The UART Boot Host display was:

 

 

(File IO): Read 168072 bytes from file C:\Temp\IPL_ACB_DSP_Release_2_0_1UART1.bin.

(Serial Port): Opening COM8 at 115200 baud...

(AIS Parse): Read magic word 0x41504954.

(AIS Parse): Waiting for BOOTME... (power on or reset target now)

(Serial Port): Read error! (The operation has timed out.)

(AIS Parse): Read invalid BOOTME string.

(AIS Parse): Boot aborted.

(Serial Port): Closing COM8.

 

 

 

Tried to connect CCS V3.3 with OMAP Debug GEL File and got the following error message.

 

 

Error connecting to the target:

Error 0x80002240/-180

Fatal Error during: Initialization, OCS, Control,

This error was generated by TI's USCIF driver.

 

SC_ERR_CTL_NO_TRG_POWER <-180>

The controller has detected a target power loss.

The user must turn-on or connect the power supply for the target.

 

 

 

Board Name: C6747_SDXDS560R

Cpu Name: ICEPICK_C_0

 

Abort:              Close Code Composer Studio.

Retry:               Try to connect to the target again.

Cancel:             Remain disconnected from the target

Diagnostic:        Run diagnostic utility.

 

 

TEST 3:

Booted system from SPI Flash.

Connected our external DSP Monitor application via UART1 to the DSP.

Passed a few messages and got  the correct responses.

Shut down the DSP Monitor application.

Changed the Boot Mode DIP switch from 01100 (SPI 1 Flash) to 10111 (for UART1).

Connected a scope to the board’s UART header.

Pressed down the soft reset button on our board.

Reset the trace on the scope.

Released the soft reset button.

The scope never triggered with any traffic.

I'll get together with our hardware engineer to check the voltage levels for the core and IO supplies as you requested.

Thanks again for the support.

Mike

 

 

Great thanks for doing those tests, thats what we wanted to know. It seems very likely to be a power problem with your board. The CCS error means that the voltage level on the JTAG is not high enough to even connect, so thats where you should concentrate.

Jeff

Jeff,

Thank you very much.  We'll go and poke around and see what we can find.  Can you give me an idea of what voltage levels should we be looking at and what levels do they need to be?

Mike

Mainly the core 1.2V supply and the IO 1.8/3.3V. An easy place to start would be on the VCC pin of JTAG header itself when you are seeing the CCS error.

Jeff

Jeff,

We have monitors on our power supplies that reset the board if they detect a low power condition.  We are not seeing the power supply monitors tripping.

The other piece of information that might be helpful for you to know is that we have 5 boards from the previous spin which have been booting from SPI flash and running our application for 6-8 months with no known issues.  We have not been able to test the UART boot functionality on those boards because the chip clock frequency was not 24 MHz.  That constraint was one of the reasons why we had to do a second spin of the board.  Apart from the change in clock, there has only been a small number of changes to the board relating to the DSP and they have all seemed to check out as working. 

On a board from the first spin, we looked for a BOOTME but don't see it on that board either.

We are forwarding a schematic showing the power nets on our board.  We have double checked all of the pull up and pull down resistors on all of the pins for the DSP.  Is there any chance that the boot loader is checking a pin that we don't know about?

Is the boot loader code is available.  We are wondering if we could run it as an image from SPI flash to investigate the problem that way?

Mike

8468.GD_ACB_DSP_a.pdf

Unfortunately we cannot share the bootloader code. If you are working with a local TI FAE, we might be able to work something out though.

Based on the previous GEL file information, the boot loader detects UART1 boot mode, sends out BOOTME, and is waiting for a response. But in the latest experiment you are unable to even connect with CCS after the boot fails? Did anything change, or is the behavior flaky?

As an experiment can you try setting the boot pins to use UART0 and UART2 and probing the TXD outputs to see if those toggle? Also if you could provide a dump of the UART1 registers as well as the SYSCFG PINMUX registers after the boot failure, that might help us find something.

Jeff