Forums

Are you able to run the .OUT file by loading and running inside CCS? Or does your problem only surface when you try to boot the device stand-alone?

If it is the latter, have you checked out this wiki documentation and FAQ on the bootloader: http://processors.wiki.ti.com/index.php/OMAP-L138_Bootloader

Jeff

A1 : In this case, I was not able to compile the example using CCSv5, I had to use GCC, so I do not know how to load OUT from GGC using CCS.

Q1 : Is it possible to load GCC OUT using CCS ? If so, could you tell me how ?

A2 : Yes, I'm able to run in stand-alone mode for example "OMAPL138-DSP-LED-v4" where it boots via ARM and run DSP app

Thanks,

~Duy-Ky

Q1 : Yes just open CCS, connect to the target, and choose Load Program. You can select the GCC .OUT file and see if it works from there.

Jeff

Hello Jeff,

Below is a procedure I failed to debug GCC

* Open a newly-created WorkSpace

* Click on Debug - Debug Configuration - New : Select an existing Config file XDS100v2 workable for CCS project

* Edit Config file to add Program OUT file

* Right click on XDS100v2_ARM9_0 token to connect

* Check and View GEL to make sure it's there

* Click Run

There's nothing appear on Terminal, ie. it fails to run, with outout capture below

ARM9_0: Output:     Memory Map Cleared.
ARM9_0: Output:     ---------------------------------------------
ARM9_0: Output:     Memory Map Setup Complete.
ARM9_0: Output:     ---------------------------------------------
ARM9_0: Output:     Enabling Full EVM PSCs...
ARM9_0: Output:     PSC Enable Complete.
ARM9_0: Output:     ---------------------------------------------
ARM9_0: GEL: Error while executing OnTargetConnect(): Target failed to write memory at 0x01C11138.

I load a program into SPI flash to let LED blinking in stand-alone mode.

After click RUN in debug windows, LED keeps blinking, so The ARM core is not even under debugger control!

Q1 : What's wrong with my debugger setup procedure for GCC above ?

Thanks, Jeff

~Duy-Ky

Try setting the bootmode to Emulation boot, or UART boot so that the code in your SPI flash doesn't get loaded first.

Also, which versions of CCS do you have? Do you have both CCS4 and CCS5? If so, you are unable to compile the projects using CCS5?

Jeff

Hello Jeff,

I started with CCS-v4 in testing package "CCSv4-2_with_SOM-M1_BSL_WS". I'm able to run example UART in both debug mode and SPI-Flash stand-alone mode.

However, this UART has NO interrupt UART support.

I then found StarterWare with a lot of interrupt examples, including one for RX UART..

For StarterWare, I have to use either GCC or CCS-v5, but not CCS-v4.

I failed to compile using CCS-v5, but no response at all for a week after emailing to ti-support. That's why I had to try with GCC and had successful compilation.

A1 : I tried and failed per your suggestion where to use UART boot mode.

Actually, I prefer to use GCC and wish to be able to debug with CCS-v5. But I'm afraid to give up that way.

Now, I've just had a successful compilation of StarterWare using CCS-v5. The reason of my failure was I copied the Project into WorkSpace. It appears to me that CCS-v5 does not like the idea to copy Project into WorkSpace, I'm afraid.

Now, I'm able to run UART example in debug mode, I've seen a greeting message on Terminal and Echo whenever I type into Terminal.

But I still failed to run it in stand-alone mode out of SPI flash

In short, below are my latest situation

1) ABLE to compile StarterWare UART example using CCS-v5

2) ABLE to run it in debug mode

3) NOT ABLE to run in SPI flash stand-alone mode suing both OUT files (i) pre-compiled original Release OUT file (ii) newly- compiled Release OUT file where I'm able to run it in debug mode successfully

4) I'm pretty sure my flashing procedure is correct as I had it booted fine out of SPI flash with another image from example "OMAPL138-DSP-LED-v4"

Q1 : As I have no problem in debug mode, while stand-alone mode NOT working. So, something not quite right with Start-Up code. Do you have any idea ?

Thanks so much, Jeff

~Duy-Ky

Duy-Ky,

You're right; the StarterWare projects should be imported to CCS5 without copying the project files into your workspace.  This matters because the StarterWare projects specify file locations (source code, headers, libraries, etc.) using relative paths.  Therefore, the project files must be located in their original location for the build to work correctly.

To boot directly to a StarterWare application, we recommend using the bootloader utility that's included with the package.  This utility helps manage the PLL and EMIF settings that the GEL file handles during development/debug.  For more information, please refer to the Quick Start Guide on the wiki.  More detailed documentation for the boot process is forthcoming, but the basic procedure is already documented there.

Have you gone through the FAQ #3.4 on this page and verified that none of these conditions apply to your code: http://processors.wiki.ti.com/index.php/OMAP-L138_Bootloader? It is very likely due to supervisor/user mode and/or GEL file reliance.

Jeff

Hello Jeff,

Yes, I did pay close attention to supervisor/user mode as I got quite some time working in PowerPC  Embedded Linux and I learned ARM9 has that protection feature.

However, I'm able to do flashing UART example from thge package CCSv4-2_with_SOM-M1_BSL_WS and it works great in stand-alone mode with output on PC Terminal.

So, I assume StarterWare should behave the same!

Thanks, Jeff

~Duy-Ky

I suggest starting with this debug step from the FAQ:

* Compare the PLL, pinmux, and DDR registers after booting and verify they match what the GEL file sets them to.

Jeff

Hello Joe,

Thanks so your explain of the feature "not to copy". I found no problem with this feature.

Yes, you're absolutely right as I'm ABLE to run BootLoader example in stand-alone mode out of SPI Flash with output on Terminal

StarterWareAM1808 Boot Loader
Invalid magic number in boot image

Actually, using BootLoader is exactly what I'm after as we will have 2 images for our prototype : DSP & ARM. I'm working on ARM side and my friend on DSP.

I'm able to run in stand-alone out of SPI flash for example UART from the package CCSv4-2_with_SOM-M1_BSL_WS, so I thought UART example from StarterWare behave the same.

Now, in my situation, I have 3 OUT files compiled separately : bootloader, ARM and DSP.

Q1 : How to change BootLoader to load ARM and DSP image ? It's easier to understand how bootloader works with ARM and DSP code

Q2 : Is it possible to load these 3 images at some pre-defined flash addresses so we can erase and program the flash independently ? It's easier in development phase

Q3 : Is it possible to combine these 3 images into a single file for flashing ? It's easier in production phase

Thanks so much for your great help, Joe

~Duy-Ky

Duy-Ky,

To boot a StarterWare application using the secondary bootloader, you only need to flash two files:

1. An AIS image generated by AISgen (from boot.out)
2. A binary image generated by out2rprc.exe (from your application .out file)

You can flash both files using the standard SFH utility.  Example usage is provided on the wiki page linked by my previous post.  SFH does flash these components at preset locations in the flash memory.  This is also documented on the wiki:

• http://processors.wiki.ti.com/index.php/Serial_Boot_and_Flash_Loading_Utility_for_OMAP-L138

Using the terminology from this page, the bootloader AIS file is the "UBL" that is flashed to offset 0, and the application image is flashed to offset 0x10000.

If you want to load both ARM and a DSP applications at boot time, you may want to skip the StarterWare bootloader and combine both application binaries into a single AIS file.  In this case, you would only need to flash a single file (using SFH or any other flashing utility).  The only challenge will be to make sure your AIS file applies the correct PLL and EMIF configuration required by your application(s).

Hello Joe,

Currently, I've been using JTAG port for flashing.

I modified the example SPI in StarterWare and able to erase and program SPI flash. Using this way, I load the example BootLoader and it boots and works sucessfully. In doing so, I use AIGgen tool to convert from OUT to AIS file for flashing.

Per your info, I'm supposed to do the followings

1) Load BootLoader.AIS at SPI_addr 0

2) Load ARM_image.AIS at SPI address 0x10000

3) As OMAP-L138 is a ARM-boot device, Combine ARM.Out and DPS.Out into a single AIS file and load at SPI Address 0x10000 as in (2)

Am I correct ?

Thanks so much, Joe

~Duy-Ky

Duy-Ky,

The last item is an alternative procedure, not a third step in a single procedure.  The version of out2rprc that you have does not support merging two application .out files into a single binary image, so your only option for ARM + DSP is to use AISgen instead.  The next release of StarterWare will include an updated out2rprc tool so that this is no longer necessary.

Currently, your options are:

1. Load bootloader AIS to flash address 0
2. Load ARM application image (generated by out2rprc) to address 0x10000

... or:

1. Load combined application AIS (ARM + DSP) to flash address 0

The next release of StarterWare will add support for ARM + DSP applications to the first procedure.

Hello Joe,

You must be a guru in this field, Joe

A1. Load bootloader AIS to flash address 0

   YES. I got it SPI_Flash booted using UART example in the package CCSv4-2_with_SOM-M1_BSL_WS in CCS_v4 from LogicPD (but all code from TI)

           CCS_V4 compiles to get OUT file

           AISgen to convert OUT file to AIS file

          Program SPI_Flash AIS file using SPI example in this package via CCS_v4 and XDS100v2

A2. Load ARM application image (generated by out2rprc) to address 0x10000

   YES. I got it SPI_Flash booted with UART example from StarterWare AND BootLoader example

          CCS_v5 compiles both BootLoader and UART example

          AISgen.exe converts BootLoader.OUT to BootLoader.AIS

         Out2Rprc.exe converts Uart.OUT to Uart.BIN

         sfh_OMAP-L138.exe erases and does flashing both BootLoader.AIS and Uart.BIN at once

A3. Load combined application AIS (ARM + DSP) to flash address 0

     YES. I got SPI_Flash booted with OMAPL138-DSP-LED-v4 example in CCS_v3 format

            CCS_v4 imports Legacy CCS_v3 as 2 projects ARM and DSP to get Arm.OUT and Dsp.OUT

           AISgen.exe combines these 2 OUT files into One AIS file : Arm.OUT + Dsp.OUT -> Arm_Dsp.AIS

          Program SPI_Flash using SPI example in this package via CCS_v4 and XDS100v2

 So, using StarterWare, I'm able to get SPI_flash booted using BootLoader for ARM app using serial loader SFH tool, as you helped me

When I do flashing Uart.BIN directly to SPI address 0x10000 using XDS100v2, it fails to boot.

I compared contents in two cases : using serial SFH tool and direct SPI flashing, I found some MAGIC data of 20 bytes are appened at beginning of Uart.BIN.

Q1 : How to calculate these 20 bytes so I could add to BIN file for direct SPI flashing ?

Q2 : Or is there any tool to add these MAGIC data to BIN file (after Out2RpRc.exe) for direct SPI flashing ?

Thanks so much for your great help, Joe

~Duy-Ky