(Please visit the site to view this file)(Please visit the site to view this file)(Please visit the site to view this file)(Please visit the site to view this file)(Please visit the site to view this file)(Please visit the site to view this file)
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.
- Gel file reliance/ Incorrect external memory (DDR2) configuration: Please see AIS configuration and Gel settings files attached.
- ARM supervisor mode: I am using boot.asm that is included in the example.
- KICK registers unlocking: Though my device revision is 2.1, I do this unlocking.
- 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