Boot Basics on OMAP-L138 Logic PD SOM?

MikeH said:

I understand that the ARM is the master device in the OMAP-L138 and will attempt to boot from the storage device identifed by the BOOT[0:8] pins, which I will program to 0x0C using dip switches on my board.

I want to clarify with you (perhaps it was a simple typo), but there are only 8 BOOT pins on the OMAP-L138 per the datasheet.  Table 3-15 on page 49 indicates this.  Also, this may be semantics, but for SPI1 Flash boot, the BOOT pins should have resistor straps to configure it to 00001100b where the first digit represents BOOT[7] and the last digit represents BOOT[0].  In your statement above, it is unclear to me if you accidently added an ninth BOOT pin (ie. BOOT[8]) and if you intended the order assignment of BOOT[0:8] = 0x0C, which would not have set BOOT[3]=1 or BOOT[2]=1.

Again, I may be reading into this way to much, but I wanted to clarify.

MikeH said:

I also understand that I can generate a boot image by using AISGen which will generate a boot image from my CCS .out file, and will generate code for various key elements of the OMAP such as PLLs, Pinmuxes, and external memory.

What I don't understand is:

1. How to get my boot image file (project.ais) programmed into the SPI flash on the SOM. Can this be done via my emulator connection using CCS? If not what other methods are available?

This is a great question and at least from my perspective has 2 possible solutions.  The first is actually more geared for when you are in mass production of your product, which one would use their manufacturing board test fixture to directly stimulate the signals on the SPI flash via some header mounted on the board, or a bed of nails test fixture.  This is generally done when minimizing the test time per board is paramount or one has the appropriate equipment to configure and program as it allows you to eliminate a lot of intermediate steps such as 1) connect to processor in some way, 2) use an alternate boot mode to interact with processor, 3) download a custom program whose sole purpose in life is to program the non-volatile storage device, 4) etc.

That said, the 2nd solution is essentially what I just described regarding the steps above.  This is the essentials behind the Serial Boot and Flash Loading Utility article on the http://procoessors.wiki.ti.com site for OMAP-L138.  In this particular utility, the UART boot mode is targeted as the process is driven by an external host, in this case a PC or workstation in general.

The OMAP-L138 ROM code, when supporting this UART boot mode, has enough intelligence and a state machine that interacts with a host to parse and perform the commands sent to it using the format defined by the AIS scripting language.

MikeH said:

2. I understand that there is a bootloader application resident on the SPI flash chip, however I do not have a serial connection on my board.

If I read your statement correctly, you do not have a serial connection.  Even more specifically, you do not have UART0, UART1 or UART2 on your board to implement the above Serial Boot and Flash Loading utility methodology, correct?

Is it possible you have test points for these interfaces that you could access?

MikeH said:

I do have a USB client connection on my board. Can this somehow be used to program the flash memory?

Unfortunately, not on this particular processor.  Other devices do have support for a USB boot mode where the device acts as a USB client to a host PC or workstation and a similar process to the above Serial Boot and Flash method would be used.  But as I mentioned, this is not supported on the OMAP-L138.

So, what to do?  If you have made it this far into my response, don't lose hope.  You asked about the JTAG connection to the processor and utilizing Code Composer Studio.  And more specifically you asked if programming and erasing the SPI flash can be accomplished by the emulator connection using JTAG and CCS.

Yes, it can be done.  Just keep in mind, that CCS itself does not natively have support for such activities.  But its role in life is to provide a development environment for your application development and provide facilities to download that application into the processor and provide you visibility to the inside of the device while running, single-stepping, etc.  Therefore, this is same basic principle to what the above Serial Boot and Flash method is, with the twist that the ROM code is not executing on the OMAP-L138, but rather a custom, single purpose application which you just downloaded via CCS->Emulator->JTAG->OMAP-L138.  This small application would need to have the SPI flash programming and erase algorithms in it, a small state machine that handles commands to run the algorithms and support for some interface to download the image.  This could be JTAG which you might download the image into memory.  If the memory is not large enough for your image, then download the image in manageable chunks.

Does such a program exist for the OMAP-L138?  That I am not aware of, but the fundamentals of that program are in the Serial Boot and Flash Utility.  The reason I say this is that a portion of the article mentioned above talks about what would need to be modified to support a custom target board.  The Serial Boot and Flash Utility, as downloaded, is targeted for the EVM only.  One would need to perhaps modify some of the files to support a different flash memory device, different DRAM device (ie. timing parameters), clock frequencies, etc.