I'm trying to run StarterWare UART example on OMAP-L138 Experimenter Kit.
+ able to compile using GCC
+ NOT able to compile using CCSv5 (the only version CCS can be used, not earlier version)
+ Able to convert to AIS file from GCC OUT file
+ Able to do flashing on to the board correctly.
+ Not working. There's nothing on the terminal, no UART echo, ...
+ 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
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
Please click the Verify Answer button on this post if it answers your question.----------------------------------------------------------------------------------------------------------
Useful Links:OMAP-L1x/C674x/AM18x Debug GEL File
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
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.
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 ?
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?
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
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.
Please click the Verify Answer button on this post if it answers your question.
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.
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!
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.
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 LoaderInvalid 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
To boot a StarterWare application using the secondary bootloader, you only need to flash two files:
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).
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
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:
The next release of StarterWare will add support for ARM + DSP applications to the first procedure.
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 ?
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.