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.

StarterWare UART example problem

Other Parts Discussed in Thread: OMAP-L138

Hello,

I'm trying to run StarterWare UART example on OMAP-L138 Experimenter Kit.

*  Compiling

   + able to compile using GCC

   + NOT able to compile using CCSv5 (the only version CCS can be used, not earlier version)

* Flashing

   + Able to convert to AIS file from GCC OUT file

   + Able to do flashing on to the board correctly.

* PROBLEM

   +   Not working. There's nothing on the terminal, no UART echo, ...

* Issues

   + Able to run UART example from the package "CCSv4-2_with_SOM-M1_BSL_WS" under CCS-v4. So nothing wrong with the board and PC termianl

   + Able to get it boot and run example "OMAPL138-DSP-LED" using the flashing procedure above, including AISgen from OUT file, and using CCS-v4. So nothing wrong with AISgen and flashing procedure.

 

I'd appreciate any help to find out why StarterWare UART not working for me

 

Thanks,

~Duy-Ky

 

  • 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:

    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

  • Duy-Ky,

    You're right; the SFH tool does insert some header information before the binary file that it writes to offset 0x10000 in flash memory.  The contents of this header are as follows:

    typedef struct _spibootheader_ {
        unsigned int magicNum;
        unsigned int entryPoint;
        unsigned int appSize;
        unsigned int memAddress;
        unsigned int ldAddress;
    } SPIBootHeader;

    The StarterWare bootloader expects the entire 20-byte header to be present at the beginning of the application, but it only looks at the magicNum and appSize fields.  If you don't use SFH, you will need to set these values correctly for your application.  The appSize field should be set to the size (in bytes) of your application binary file (i.e. the file generated by out2rprc.exe).  The magicNum field should be set to one of the following values (either should work):

    0xA1ACED00
    0x55424CBB

    Hopefully this will help you get started.  A lot of this information will be documented on the wiki in the near future.

  • Hello Joe,

    Our current project is to make a receiver to test and evaluate wireless network to sell in US (AT&T, Verizon, T-Mobile, ...) Canada, Europe and China. It has 2 OMAP-L138 to process for I & Q data using 2 DSP cores, but only one ARM for user interface. So, to be flexible and easy to use in all situation where it's not sure the size of ARM and DSP image, it's good idea to have bootloader with feature to allow us to set start of ARM and DSP image in flash at sector boundary. Currently, I found the bootloader has ARM image at 0x10000, so the 1st sector for boot image, and the 2nd for ARM in a 8MB flash of 64KB-sector. It's totally makes sense to me.

    It's very convenient if we could configure the future bootloader to get DSP start at some sector address. In addition, in all our product here, we also store FPGA image in flash too.

    We really appreciate if you could have a close look at our opinion in the next release of StarterWare in terms of bootloader

    Our plan is to have our prototype ready to bring up in 2 months, so I'm wondering if you could let me know an estimate time frame to release next StarterWare so we could test both ARM and DSP in stand-alone mode out of flash.

    Best Regards,

    ~Duy-Ky