Boot from UART

Hi Matan,

Matan says said:

 Is there a tutorial for loading an application using UART?

yes, of-course, the following wiki link will guide you to load the application using UART.

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

Matan says said:

 Do you have advice on how to get this working? It looks like the tools are pretty straightforward,  but the application is not working.

1. Have you done appropriate Boot switch settings ( as given in the above wiki; particularly for Logic PD) after the binary of the application has been flashed ?

2. Are you running the TI supplied LED blink examples? or your own? If it is supplied by TI, which one you are using? is it from rCSL Examples http://processors.wiki.ti.com/index.php/QuickStartOMAPL1x_rCSL ? or from starterware? Specify the software package name and its version

Regards,

Shankari.

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

Please click the Verify Answer button on this post if it answers your question.
--------------------------------------------------------------------------------------------------------

Hi Shankari,

Thank you for your reply.

The tutorial you posted does not contain important information about this procedure. Specifically, it does not explain that when using OMAP-L138, you need to create an ARM application that fires up the DSP application. It looks like the most crucial part is telling the ARM application where the DSP application starts, and setting the DSP's starting point to a fixed address. I found these two sources very helpful:

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

http://processors.wiki.ti.com/index.php/C6000_Embedded_Design_Workshop_Using_BIOS#Booting_From_SPI1_Flash_Using_OMAP-L138_.28OMAP-L138_SOM.29_or_C6748_EVM_.28C6748_SOM.29_-_Procedures_and_Files

(specifically the last section in the second link).

Anyways, I was able to load the flashing LEDs examples via UART. I tried the exact same procedure with my application, but it didn't work... Needless to say that the application is running great when loading via CCS.

Here's what I did:

1. Set the DSP's starting address to a fixed value by adding the following line to my linker cmd file:

.text:_c_int00 > 0x11830000

2. Create a binary AIS file using AISgen and the attached configuration file. I used the ARM bootloader Eric Wilbur supplied in the SYS/BIOS labs. 8176.OMAP-L138-ARM-DSP-LAB14B_TTO.cfg

3. Load the binary file to the board using the UART host.

The first thing my application does is blink the LEDs, so that I would know it's alive. Unfortunately, it is not.

As I said earlier, I tried the exact same procedure with another application and it worked great. The only thing I changed was the DSP's out file.

I'd really appreciate some help with this one, this is the last step we need to complete to finish this project. 

Can you think of a reason why this shouldn't work?

How can I debug the issue?

Many thanks,

Matan

Matan,
For setup and bootup the EVM board quickly, you need the UART download or CCS version flash tool for the board.
The default flash storage is SPI flash on eXperimenter board and NOR/NAND flash are all on the UI board.
UART boot and download tool, Refer to the link Serial_Boot_and_Flash_Loading_Utility_for_OMAP-L138.
You need to change the code to according to your own board configure(DDR2 and flash driver)
and recompile the executable program.
Will you double check the entry point?
-APPStartAddr       : Changes entry point of application (default 0xC1080000)
-APPLoadAddr        : Changes load address of application (default 0xC1080000)
Verify the boot pins for UART(Switch7) as per the wiki page for logicPD board.
For UART boot mode, the bootloader transmits the ASCII string BOOTME to the host before it is ready to
begin SWS.

Hi Pubesh,

I was able to verify that the application starts properly. I booted using UART and then connected with CCS to see where the program is stuck. It was stuck on address 0x11832804 which I traced back to a call to the function "Timestamp_get32". I rewrote the code without this function, and then boot got a bit better, but not perfect.

Let me describe what I did, maybe it will give us a clue to why the program is running when booting using CCS but not via UART.

I added the following code to my main.c to have the LEDs blink when the application starts:

USTIMER_init();

LED_init();

flashLEDs();

And indeed, the LEDs flash after UART boots successfully. However, there is no output sound! When booting via CCS the LEDs flashed and then sound was available at the output.

Now, my program is based on Eric Wilbur's SYSBIOS Lab no. 4 (swi_task_audio). In Eric's code there is an alternative implementation of the function USTIMER_delay, with the following comment:

// LogicPD BSL fxn - re-written for a few BSL.c files that need it.

// The original USTIMER_init() is not used because it is NOT BIOS compatible

// and took both timers so that BIOS PRDs would not work. This is a 

// workaround.

//

// If you need a "delay" in this app, call this routine with the number

// of usec's of delay you need. It is approximate - not exact.

// value for time<300 is perfect for 1us. We padded it some.

Now, that got me thinking maybe USTimer is the problem...

Anyways, it's a mess, and I'm not really sure how to debug it.

I tried connecting again with CCS after boot is completed and see on what address the application is stuck. I got to address 0xc0201624, but I was unable to trace it back and realise what function is generating the problem.

I'm sorry for the long and unordered post... this is very frustrating - I don't see why the code that runs perfectly with one way of booting should fail in another. How do you explain that the function "Timestamp_get32" was working with CCS boot but not with UART boot?

Do you have any suggestions on how debug the issue?

Specifically, how can I know which function in my code is generating the problem?

Thanks,

Matan

One more thing - 

I ran the debug GEL file for diagnosis of my environment, once when I booted with CCS and the other when I booted via UART. There were two differences:

on CCS boot I had PLL0_SYSCLK3 = 25 MHz while in UART boot I had: PLL0_SYSCLK3 = 300 MHz.

on CCS boot I had 

Module 8:  SATA               STATE = 3

while on UART boot

Module 8:  SATA               STATE = 0

Do you think that these differences can influence this issue?

Thanks,

Matan