UART boot for OMAP L138 experimenter kit

The OMAP-L138 is an ARM boot device, so whatever .bin file you load with the UART Boot Host utility must be compiled for the ARM. 

Jeff

What do you mean "compiled for the ARM" ? the build from CCS and the production of the .out ? this file when downloaded from usb works fine.

If you mean the production from out -> bin with the AISgen tool that I should choose device type ARM, I cannot understand the reason. (I tried that though and stil nothing)

I use the experimenter kit which has no ARM processor.

The experimenter kit comes with the OMAP-L138 SOM, which has both an ARM and a DSP. If the silkscreen on the device says "OMAP-L138" then it is an ARM+DSP device. If it says "C6748" then it is DSP only. Can you verify which one is connected to the baseboard?

Jeff

You are right, my device is "OMAP-L138"

I built the test_led_dip.prj and downloaded from mini usb and it worked.

Is there something different for compiling the test_led_dip.prj to build the .out  to produce the AIS .bin to boot from UART?

Hi Nasos,

I guess you must input a raw binary application image  to the aisgen utility, not the one with the *.out extention. Out file can only be loaded by the CCS.

Check for a tool called "hex470.exe" to convert .out file to raw binary. Than use this binary to generate your ais image.

If you don't have hex470 in your environment, check for TI Code Generation Tools package. [1]

Hope this helps.

Alper

 [1] - https://www-a.ti.com/downloads/sds_support/TICodegenerationTools/download.htm

Alper,

Actually the AISgen tool can take both COFF and ELF inputs and convert them to AIS format. CCS .out files are in the COFF format, so they can be used directly.

Using the tool you mentioned to convert the .out to a raw binary would only work when the .out is a single monolithic program without loading different sections to different memory locations.

Jeff

Thanks Jeff, I did not know that,

Sorry for the wrong information.

I have stil some questions:

I downloaded the Boot Images from the link above and they work fine:

- the pre-built .bin files boot from UART ok

- the pre-built .out files, when I generate the bin with the AIS tool gen, and download it through UART works fine!

But when I try to compile  the included project from CCS3.3, the .out and then the .bin file does not work!

By the way, when I compile the included examples of NDK and download them from mini usb , they work.

What do I need to change (build options, gel files, etc) so I can build the project from the above link and make a .out file similar to the pre-built one?

The build options are saved in the project and don't need to be modified.

Can you post the text of the "Build" window when you Rebuild All in CCS? This will tell us what versions of the tools and any warnings that came up.

Also please download this GEL file and connect to the ARM. It will print out any boot loader error messages, as well as the current PC. Paste the results here as well.

Jeff

The output of the build window is

------------------------  OMAPL138-ARM-LED.pjt - Debug  ------------------------
[main.c] "C:\CCStudio_v3.3\tms470\cgtools\bin\cl470" -g -pdsw225 -fr"C:/CCStudio_v3.3/MyProjects/OMAPL138-ARM-LED/build/../Debug" -i"C:/CCStudio_v3.3/MyProjects/OMAPL138-ARM-LED/build/../include" -d"_DEBUG" -me -mv5e --abi=ti_arm9_abi -@"../build/Debug.lkf" "main.c"

[Linking...] "C:\CCStudio_v3.3\tms470\cgtools\bin\cl470" -@"Debug.lkf"
<Linking>
>> warning: entry point symbol _c_int00 undefined

Build Complete,
  0 Errors, 1 Warnings, 0 Remarks.

When I connect to the board through mini usb (XDS100), after reset, the info of the output window is

---------------------------------------------
|               BOOTROM Info                |
---------------------------------------------
ROM ID: d800k004
Silicon Revision 1.1
Boot Mode: SPI1 Flash

ROM Status Code: 0x00000001
Description: DSP was put to sleep

Program Counter (PC) = 0x80000000

When I convert the produced .out file to bin and restart the board at UART2 boot-load mode, I cannot connect to the board through mini usb to get further info.

I also cannot load directly the produced .out (or the original one) through mini-usb. I get "does not match the target" msg. Does this make sense?

I attach the .map file of my production.

Another issue is that I see only the main.obj file to be produced (before .out).

What about the handler.obj, intvest.obj and also initstack.obj that I see at the downloded folder?

The XDS100v1 cannot connect to the ARM processor, so you won't be able to load any .out files to the ARM via the mini usb. If you connect to the DSP and try to load an ARM .out, you will see the "does not match the target" message.

Additionally, since the pinmux setup is done via AIS, loading the .out directly will not blink the LEDs on the board.

Can you attach the compiled .out file for me to try myself? Thanks

Jeff

I attach the compiled file

Jeff,

How could I connect to the DSP from XDS100 or XDS510USB to debug application after the board has booted from UART?

I use the original .bin file that I downloaded or the one I produced from the downloaded .out (they both work fine), I switch the S7:7 and S7:8 pins to on, the board boots and the application runs. Is there a way to connect from CCS3.3 to debug while the application is running?

Thank you

This issue you are seeing is because during compile it is not pulling in the "rtsv5_A_le_tiarm9.lib" which defines the entry point c_int00. If this is not found, the entry point defaults to 0x00000000, which is why you code doesn't run properly.

I've explicitly included that in the project file now, so please download the new project below:

http://processors.wiki.ti.com/index.php/Boot_Images_for_OMAP-L138#Obtaining_the_software

You might want to reinstall the TMS470 Code Generation Tools, which sets up the path for the lib. Alternatively, you can do it manually, by adding the path to the library to you windows  PATH variable. For example, it should be located at "C:\Program Files\Texas Instruments\TMS470 Code Generation Tools 4.6.3\lib"

Jeff

If the DSP hasn't been woken up yet, you will not be able to connect to it for debug. This application is running on the ARM so debugging the DSP wouldn't be useful anyway.

Jeff