Update for StarterWare on AM1808, OMAP-L138, and C6748

Hello Joe,

I've been waiting this update for quite a while in order to boot OMAP-L138 with 2 separate images DSP + ARM.

I have few questions below

1) I've learnt that AISgen used for bootloader and Out2RpRc for Application. When I check properties of these 2 utilities from old and new version, they appear the same in terms of file size and date create ???

2) Is this release a solution to my boot problem with 2 separated image DSP + ARM ? If so,

     2.1) where I could find detailed info for this job with 2 images ?

     2.2) Out2RpRc used for App_Image, so how to deal with DSP & ARM images ?

     2.3) In previous version, I use Out2RpRc to create bin file and do flashing at address 0x10000. Now for this version, what flash address in case 2 separate images after Out2RpRc for DSP and ARM ?

3) I guess I can use the same magic code added to start of App image for bootloader to work ?

    3.1) Is there new magic code in case 2 App bin images DSP & ARM ?

Thanks,

Happy Holiday, Joe

~Duy-Ky

Duy-Ky,

The AISgen tool has not changed in the new release, but out2rprc has changed.  For details on the new out2rprc utility, please refer to the tools/out2rprc/README.txt file in your StarterWare installation.  This README file also contains the basic procedure for preparing, flashing, and booting an ARM + DSP system on OMAP-L138.  We will ultimately put this information on the TI wiki as well to make it easier to find.  Here is a quick summary:

1. Use CCS or make to build your ARM and DSP applications.  For compatibility with the bootloader utilty, do not place any initialized sections in L3RAM.
2. Run the out2rprc utility convert your application into binary format:
   
   out2rprc.exe <app 1 (*.out)> <app 2 (*.out)> <output file name (*.bin)>
   
   Note that the ARM application file should be specified first.
3. Flash the bootloader utility AIS file and your application binary using the serial flasher (SFH) utility: sfh_OMAP-L138.exe -flash <bootloader (*.ais)> <application (*.bin)>

Overall, the process is very similar to the ARM-only usage in the original release of StarterWare.  The major difference is in step 2, above.

Please give this a try and let me know if you have any additional questions.

Hello Joe,

I knew there must be something new in Out2Rprc.exe to handle both ARM and DSP apps, so I did pay close attention to that utility.

Unfortunately I kept looking README.TXT at a wrong folder "tools" many times, even after I had moved the old folder "tools" and replaced by the new one.

Now I'm able to combine both ARM and DSP apps into a single binary file and booted up.

In my test

0.1) DSP puts out a UART messahe "Hello from C674x DSP-OMAPL138"

0.2) DSP blinks LED forever

0.3) ARM puts out its own UART message "Hello from TI ARM9+DSP CCSv5 2012-01-06a"

0.4) ARM runs interrupt routine to detect if Button is pressed

It appears running BUT NOT properly and I'm not sure whether I did the test properly

Below are my test procedure

1) In debug mode for DSP, I ran the example "I2C" but with some mods

     1.1) Add UARTStdioInit(); and use UARTprintf("Hello from C674x DSP-OMAPL138\n\r");

     1.2) Change BlickLED from a loop of 100 counts to FOREVER loop

     The debug test appears running properly

     1.3)with message "Hello from C674x DSP-OMAPL138"

     1.4) and LED keeps blinking forever

2) For ARM_ONLY bootloader, I got screen capture

StarterWare AM1808 Boot Loader
Jumping to StarterWare Application...

Hello from TI ARM9+DSP CCSv5 2012-01-06a

>> GPIO ID 00000000 DIR fff7ffff

$ > Pushbutton was released

> Pushbutton was pressed

> Pushbutton was released

> Pushbutton was pressed

So, the interrupt routine runs properly with response to Button pressed in ARM_ONLY bootloader

3) However, after combined with ARM app, running in stand-alone mode suing bootloader, I have the screen capture below

    3.1) Without mods in the example "I2C", ie no UART message, I got

StarterWare AM1808 Boot Loader
Running DSP Application...
Jumping to StarterWare Application...

Hello from TI ARM9+DSP CCSv5 2012-01-06a

$ > Pushbutton was released

   3.2) and the LED blinks ONLY ONCE

   3.3) With mods in the exampl,e "I2C", with UART message, I got

StarterWare AM1808 Boot Loader
Running DSP Application...
tHuemlplion gf rtoom  SCt6a7r4txe rDWSaPr-eO MAApPpLl1i8c3a
on...

Hello from TI ARM9+DSP CCSv5 2012-01-06a

$ > Pushbutton was released

   3.4) The LED blinks TWICE

   3.5) There's no response to Button pressed

Below are my observations

   4.1) DSP UART message is "corrupted" (?) with "tHuemlplion gf rtoom  SCt6a7r4txe rDWSaPr-eO MAApPpLl1i8c3a" instead of "Hello from C674x DSP-OMAPL138"

          This could be a mix between DSP and ARM UART message ??

   4.2) The LED blinks only twice, instead of forever

   4.3) The UART message from ARM is correct with "Hello from TI ARM9+DSP CCSv5 2012-01-06a"

   4.4) ARM stops responding to Button pressed

So, could you tell me what's wrong with my test above

Thanks so much, Joe

~Duy-Ky

Duy-Ky,

I have personally tested a combined application use case similar to the one you describe.  In my case, I used the UART example for the ARM application and the I2C "LED blink" example as the DSP application.  These applications work well together, so I recommend you try the same thing to make sure that you can successfully boot an ARM+DSP system with "known" applications.

That said, there are several things that could go wrong with when using your own custom applications for ARM and DSP:

1. The ARM and DSP application memory maps could overlap.  (You can check whether or not this is the case by looking at the CMD or  MAP files.  The out2rprc utility should also print a warning if initialized sections from the two applications collide with one another.)
2. The ARM and DSP applications may conflict if they attempt to use the same peripheral at the same time
3. The DSP application entrypoint may not be properly aligned. (The DSP entrypoint, typically _c_int00, must be aligned to a 1024-byte boundary. The bootloader will print an error message to the UART terminal if this requirement is not met.)
4. The ARM or DSP application could conflict with the bootloader memory map (could also happen in ARM-only or DSP-only systems)

Based on your description, I would say that issue #1 is the most likely explanation for your issue.  Could you provide the linker command files for your ARM and DSP application so we can check whether or not this is an issue?

It may also be a good idea to try loading the ARM and DSP applications in the same debug session using the emulator to see if the same problem occurs.  If you try this, please use the following procedure:

1. Start combined debug session in CCSv5
2. Connect emulator to ARM core
3. Connect emulator to DSP core (can use same emulator)
4. Load ARM application
5. Load DSP application
6. Run DSP application
7. Run ARM application

You can also experiment with reversing the order of steps 4 and 5 or 6 and 7.