How to do SPI Flash programming on the OMAP-L138 using XDS100

Samuel,

Have you downloaded the serial flashing and boot utilities.

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

The package contains a SPI writer CCS project. Boot your device in Emultation boot mode, connect to the device using your XDS100 and then run the SPI writer CCS project to write your boot image to the SPI Flash. There is another option which I believe will suit your usecase even better. We provide a serial flashing utility called sfh in the serial flash and boot utilities which will program your SPI by reading your AIS boot image over UART. Please look for this utility under the OMAPL138/GNU folder .

Hope this helps

Regards,

Rahul

Rahul,

Thanks for the link, I am looking only at using the CCS to write my application to the Flash. I have downloaded and ran the SPIWriter_DSP project file but I always hit a problem when it goes to fPtr = fopen("fileName", "rb"); it seems to freeze once I step over this point. (spiwriter.c).

So I tried single stepping in assembly code and found that once the fopen loads the "c:\led.bin" right after the last letter goes into the memory....it jumps to location 0x00000000 of the memory. I am not sure why its doing this. Is it because I am using CCS 5.x? instead of 3.x? Which the project was created for? Please advise.

Thanks,

Samuel

Samuel,

The version of Code composer studio shouldn`t create an issue with the way DSP executes the SPI writer. Do you see any message in the console window that indicates that the process of loading the boot image over emulator and then programming the flash completed successfully? If you are using the EVM for testing you can try the prebuilt boot images that we have provided here to see if this works for you.

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

Regards,

Rahul

Hi Rahul, Thanks for the support was able to get the SPI flash programed with another method. Now I have another question, I got the output file as led.out using the DSP as the compile environment instead of ARM. I cant seem to be able to get the application running on when I power up the board. The memory location on the linker.cmd is at the SHRAM location @ Shared RAM location where its used in .text when I compiled the program. Could that be the reason or does it need to go thru the AIS to get a BINARY out than loaded?

Samuel,

OMAPL138 is a ARM boot device, so on this device ARM needs to wake up the DSP so that the DSP can run its executable. Since you have built the led.out for the DSP environment, you need to use a simple ARM secondary boot loader(UBL) that wakes up the DSP and tells the DSP the entry point to the executable. The ARM UBL is provided in the the Boot examples that are provided on the wiki that I pointed to. You need to find out the entry point for the executable you have generated and provide that in the UBL or you can use the same UBL that we have provided by forcing the entry point of executable to 0x80001000 by using this statement in the linker.cmd file of your DSP application.

-stack          0x00000800 /* Stack Size */
-heap           0x02500000 /* Heap Size */

MEMORY
{
  L2RAM          org=0x11800000 len=0x00040000 /* DSP L2 RAM */
  DRAM        org=0xC0000000 len=0x04000000 /* SDRAM */
  entry_point:     ORIGIN = 0x80010000  LENGTH = 0x00000080
  SHARED_RAM  org=0x80010080 len=0x00007F80 /* DDR for program */
  AEMIF       org=0x60000000 len=0x02000000 /* AEMIF CS2 region */
  AEMIF_CS3   org=0x62000000 len=0x02000000 /* AEMIF CS3 region */
}

SECTIONS
{
  .text:_c_int00 > entry_point
  .text  > SHARED_RAM
  .const > SHARED_RAM
  .bss   > SHARED_RAM
  .far   > SHARED_RAM
  .stack > SHARED_RAM
  .data  > SHARED_RAM
  .cinit > SHARED_RAM
  .sysmem  > DRAM
  .cio  > SHARED_RAM
}

Refer to to the description for booting DSP binaries mentioned below:

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

Let me know if you have any follow up questions

Regards,

Rahul

PS: Verify that your executable runs by loading it through CCS. When booting from Flash take care that you do all device PLL, Pin Mux setting (EIther through AIS setting or in code)before you call into required functionality as booting from Flash is different from the GEL file based environment and if you have any issues you can use this GEL file to determine what went wrong during the boot process:

http://processors.wiki.ti.com/index.php/OMAP-L1x_Debug_Gel_Files

Rahul,

This very good advice, I managed to get the ARM LED working with the flash programming, now about the UBL, I am not sure where to get one that will work with the above mentioned linker.cmd settings.I tried using the one from the Flash and boot util 2.40 -> ubl_OMAPL138_SPI_MEM.out + led.out and generate the AIS, but it didnt seem to work. If the UBL file is correct is there something I am missing here?

Samuel

Samuel,

If you downloaded the code from the Boot Images for OMAPL138 wiki article under the OMAPL138_DSP_LED folder, you have a ARM folder that contains the sample ARM UBL that is used with the DSP LED blink example. Essentially it contains a boot.asm file that puts the ARM in priveledge mode and a main.c file that puts the entry point of the DSP executable in the HOSTCFG  register and wakes up the DSP.. While using the ARM UBL ensure that the sections in the ARM executable and the DSP executable are not overlapping and generate a map file for the DSP executable and ensure that the linker has the cint00 symbol at the address that you provide to the HOSTCFG register.

Let us know if you have any issues.

Best Regards,

Rahul

Rahul,

Thanks for all the help its working as per what you mentioned. However I hit a small problem. It seems that on the linker file if were to use the external memory. It doesnt seem to be going into that address (DDR) I am using the 0xC0000000 as the external address location. Is there something I need to do cause the problem is that my program can no longer fit in the SHRAM 0x8001000 location any more. 

Samuel