OMAPL138 Bootloading using NOR Flash and AIS

Custom_Gel_Settings.rtfdsp-cmd.rtfgel_diagnostics.rtfAIS_Custom_Config.rtfarm-cmd.rtfboot.rtf

Hi,

I have a custom OMAPL138 board and I am trying to bootload ‘blinking LED’ code that works in CCS. I am using AIS tool to generate .bin file. I am following the instructions for booting DSP binaries given in http://processors.wiki.ti.com/index.php/Boot_Images_for_OMAP-L138 . Also I have referred to http://processors.wiki.ti.com/index.php/OMAP-L138_Bootloader#How_do_I_boot_a_DSP_executable.3F

I am using same source files to generate ARM .out file that are given in the example to wake up the DSP and am using my DSP .out file to blink LEDs.

I have generated *.bin using AIS generation tool. I tried giving entry point, but got “can’t specify and entry point without at least one binary file” message. Anyway I could generate *.bin file without it, and the entry point is specified in ARM boot code and DSP linker command file.

I have successfully burnt my NOR flash with this .bin file using NOR flashing utility.

After disconnecting JTAG and after configuring boot pins to NOR boot mode, LEDs don’t blink upon power-up.

I have done the following checks.

1. Gel file reliance/ Incorrect external memory (DDR2) configuration: Please see AIS configuration and Gel settings files attached.
2. ARM supervisor mode: I am using boot.asm that is included in the example.
3. KICK registers unlocking: Though my device revision is 2.1, I do this unlocking.
4. Incorrect boot mode: have checked boot pins to be at proper voltages by the rising edge of RESET. TRST is externally pulled down. Please see attached Gel diagnostics file. There seems to be some discrepancy when we read data bits on EMIF bus.

Here is the code the scope read out of the flash during cold start (TRST pin pulled low):

Address               Data                       Data read from flash by emulator

--------------|------------------|-------------

00000000             00290029             00000021

00000004             41504954             41504954

00000008             58535905             5853590D

0000000C             00020000             00020000

00000010             00150001             001D0001

00000014             00010402             0000040B

The word at 00000000 was read twice, first in four byte-wide reads and then in a pair of 16-bit reads, like the rest of the data.

No hardware problems were observed in bitwise display of data on an analog scope. Addresses were all as described above. Byte addresses were observed on the BA (0:1) pins, although BA (0) is not connected to anything on our development board.

5. Using the bootloader shared memory: I am not using 0x80000000. Please see attached linker .cmd files.

6. I am using ROM auto-initialization model.

Any help regarding this problem is appreciated.

Also, our application has both ARM and DSP applications running and I should be able to boot both after I get this working. Is there anything I should be doing differently to do this?

Many thanks,

Prathibha