OMAPL137 - invalid AIS keyword after flashing

Ran,

I think this may be because of an incompatibility between flashing tools:

http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/57329/210435.aspx#210435
http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/37617/138197.aspx#138197

I heard that the software was being updated to make the tools compatible, but I'm not sure if the changes have been released yet.

-Tommy

Ran, what tool did you use to convert your .out file to AIS binary format? Can you send the CFG or INI file you used to create it? Also if possible can you attach the output AIS binary for us to look at? This doesn't seem like a flashing issue but rather something missing in your AIS configuration. Thanks

Jeff

2318.D800K003.rar

Hello Jeff and thank you for your support.

In order to generate the AIS file I'm using the latest AISgen for D800K003 (v0.7.0.0).

I'm attaching a RAR file which contains the configuration and the AIS file.

I forgot to mention that I was previously working on our custom board with D800K001, and had no problems with it after using AISgen for D800K001 (v0.9.0.0).

Since I switched to D800K003 I haven't been able to make it run independently after flashing, although the flashing process seems successful.

In the AISgen tool I've used the exact same configuration for the D800K003 as I did for D800K001.

Best regards,

Ran.

Thanks for all the info. Just so we can rule out the image itself, can you try flashing and running the following DSP UBL:

http://e2e.ti.com/cfs-file.ashx/__key/CommunityServer-Discussions-Components-Files/42/6787.dsp_2D00_spi_2D00_ais.bin

After you flash this image and boot, are you still able to connect to the DSP and if so can you print the output of the debug GEL file? If this also doesn't work, that might point to a board related issue.  Thanks

Jeff

Hi Jeff,

I've flashed the program you gave me using the serial flasher tool (sfh_OMAP-L137.exe).

I was able to connect to the DSP afterwards, and it still gives me "Invalid AIS keyword".

What could cause this?

Is there a way to tell if this program runs by itself at startup?

Thanks,

Ran. 

---------------------------------------------
|               BOOTROM Info                |
---------------------------------------------
ROM ID: d800k003
Silicon Revision 2.0
Boot Mode: SPI0 Flash

ROM Status Code: 0x00000009
Description: Invalid AIS keyword

Program Counter (PC) = 0x00712144

---------------------------------------------
|             Device Information            |
---------------------------------------------
DEV_INFO_00 = 0x9B7DF02F
DEV_INFO_01 = 0x00000000
DEV_INFO_02 = 0x0000F335
DEV_INFO_03 = 0x00000022
DEV_INFO_04 = 0x00000000
DEV_INFO_05 = 0x000003E0
DEV_INFO_06 = 0x00000000
DEV_INFO_07-DEV_INFO_08-DEV_INFO_09-DEV_INFO_10-DEV_INFO_11-DEV_INFO_12 = 8-0-62617-7-14-40
DEV_INFO_13,DEV_INFO_14,DEV_INFO_15,DEV_INFO_16 = 0,0,0,14577
-----
DEV_INFO_17 = 0x00030003
DEV_INFO_18 = 0x00000000
DEV_INFO_19 = 00000
-----
DEV_INFO_20 = 0x30303864
DEV_INFO_21 = 0x3330306B
DEV_INFO_22 = 0x00000000
DEV_INFO_23 = 0x00000000
-----
DEV_INFO_24 = 0x0702800E
DEV_INFO_25 = 0x0800F499
DEV_INFO_06 = 0x00000000
DEV_INFO_26 = 0x71E20000

The flashing tools by default uses SPI1. Do you have a SPI flash on both SPI0 and SPI1, and can you try booting from SPI1 instead? Did you modify the tools to flash to SPI0?

Jeff

I have flash only on SPI0.

I am choosing SPI0 in the AISgen tool.

I don't see a way to choose which SPI in the flashing tools I use (sfh_OMAP_L-137 and SPIflash_writer_dsp in CCS), so I as I understand it, it doesn't matter for the flashing tool, only to the AISgen. And again, I was previously working in the exact same way (SPI0, same flashing tools) with the D800K001 hardware revision, and it all worked just fine!

I would like to emphasize that were are flashing a single bin file (without a UBL) and using only the DSP core (without enabling the ARM core).

Thank you,

Ran.

Sorry you are correct, for OMAP-L137 the tool uses SPI0.

Can you verify that the image you flashed is at the first address of the SPI flash? That is where the bootloader looks for the AIS magic number, and the error you are getting indicates it did not find it.

Jeff

I tried flashing again the AIS you gave me, this time with the CCS spiflash_writer_dsp tool.

I'm choosing "dspais" as image type (which should give an offset of 0).

In the log of the flashing process (see below), it seems it starts at 0x000000, and I also get a successful read/write verification message.

I've put a breakpoint in the beginning of the read/write verification process, and saw the first 8 chars written to the flash were: 'T' 'I' 'P' 'A' '\r' 'Y' 'S' 'X'.

After finishing flashing, I performed a hard reset, and still got the same "invalid AIS keyword" in the debug GEL file.

Thanks,

Ran.

================== spiflash_writer_dsp log ===================

SF: Got idcode ef 30 16
SF: Detected W25X32 with page size 256, total 4194304 bytes
Flash page size: 256 bytes
Flash sector size: 4096 bytes
Starting SPIWriter.
Enter the image type (one of "dspais" "armubl" "uboot" "other")
dspais
Enter the File Name
E:\Projects\Bootloader\flashevm\6787.dsp-spi-ais.bin
Erasing flash at byte offset: 0, byte length: 0
SE: cmd = { 0x20 0x000000 }
SE: cmd = { 0x20 0x001000 }
SF: Winbond: Successfully erased 8192 bytes @ 0x0
Writing flash at page offset: 0, number of pages: 21
PP: 0xc0014fe0 => cmd = { 0x02 0x000000 } chunk_len = 256
SF: Winbond: Successfully programmed 256 bytes @ 0x100
PP: 0xc0014fe0 => cmd = { 0x02 0x000100 } chunk_len = 256
SF: Winbond: Successfully programmed 256 bytes @ 0x200
PP: 0xc0014fe0 => cmd = { 0x02 0x000200 } chunk_len = 256
SF: Winbond: Successfully programmed 256 bytes @ 0x300
PP: 0xc0014fe0 => cmd = { 0x02 0x000300 } chunk_len = 256
SF: Winbond: Successfully programmed 256 bytes @ 0x400
PP: 0xc0014fe0 => cmd = { 0x02 0x000400 } chunk_len = 256
SF: Winbond: Successfully programmed 256 bytes @ 0x500
PP: 0xc0014fe0 => cmd = { 0x02 0x000500 } chunk_len = 256
SF: Winbond: Successfully programmed 256 bytes @ 0x600
PP: 0xc0014fe0 => cmd = { 0x02 0x000600 } chunk_len = 256
SF: Winbond: Successfully programmed 256 bytes @ 0x700
PP: 0xc0014fe0 => cmd = { 0x02 0x000700 } chunk_len = 256
SF: Winbond: Successfully programmed 256 bytes @ 0x800
PP: 0xc0014fe0 => cmd = { 0x02 0x000800 } chunk_len = 256
SF: Winbond: Successfully programmed 256 bytes @ 0x900
PP: 0xc0014fe0 => cmd = { 0x02 0x000900 } chunk_len = 256
SF: Winbond: Successfully programmed 256 bytes @ 0xa00
PP: 0xc0014fe0 => cmd = { 0x02 0x000a00 } chunk_len = 256
SF: Winbond: Successfully programmed 256 bytes @ 0xb00
PP: 0xc0014fe0 => cmd = { 0x02 0x000b00 } chunk_len = 256
SF: Winbond: Successfully programmed 256 bytes @ 0xc00
PP: 0xc0014fe0 => cmd = { 0x02 0x000c00 } chunk_len = 256
SF: Winbond: Successfully programmed 256 bytes @ 0xd00
PP: 0xc0014fe0 => cmd = { 0x02 0x000d00 } chunk_len = 256
SF: Winbond: Successfully programmed 256 bytes @ 0xe00
PP: 0xc0014fe0 => cmd = { 0x02 0x000e00 } chunk_len = 256
SF: Winbond: Successfully programmed 256 bytes @ 0xf00
PP: 0xc0014fe0 => cmd = { 0x02 0x000f00 } chunk_len = 256
SF: Winbond: Successfully programmed 256 bytes @ 0x1000
PP: 0xc0014fe0 => cmd = { 0x02 0x001000 } chunk_len = 256
SF: Winbond: Successfully programmed 256 bytes @ 0x1100
PP: 0xc0014fe0 => cmd = { 0x02 0x001100 } chunk_len = 256
SF: Winbond: Successfully programmed 256 bytes @ 0x1200
PP: 0xc0014fe0 => cmd = { 0x02 0x001200 } chunk_len = 256
SF: Winbond: Successfully programmed 256 bytes @ 0x1300
PP: 0xc0014fe0 => cmd = { 0x02 0x001300 } chunk_len = 256
SF: Winbond: Successfully programmed 256 bytes @ 0x1400
PP: 0xc0014fe0 => cmd = { 0x02 0x001400 } chunk_len = 256
SF: Winbond: Successfully programmed 256 bytes @ 0x1500
Reading verifying the file.. Files matched

Can you provide the part number for your SPI flash on your  board?

Jeff

W25X32VSFIG

Thanks, I don't believe there are any issues with that particular flash.

Can you dump the memory contents from address 0x00F00700 until 0x00F00794 and paste it here? This will give some more information about where in the bootloader the boot failed. Thanks

Jeff

This is the dump in Hex32. Tell me you prefer it in another format.

Thanks.

0x00F00700    0x00010900    0x18000300
0x00F00708    0x00000000    0x00350004
0x00F00710    0x00000006    0x00000000
0x00F00718    0x00000000    0x00000000
0x00F00720    0x00000000    0x00000000
0x00F00728    0x00000000    0x00000000
0x00F00730    0x00000004    0x00000000
0x00F00738    0x00000000    0x00000000
0x00F00740    0x00000000    0xFFFFFFFF
0x00F00748    0x00000000    0x00000000
0x00F00750    0x00000000    0x00000000
0x00F00758    0x00000000    0x01C41000
0x00F00760    0x007F53C0    0x007F55C4
0x00F00768    0x007F5838    0x007F588C
0x00F00770    0x00000000    0x007F5E40
0x00F00778    0x00000000    0x00000000
0x00F00780    0x00000000    0x00000000
0x00F00788    0x00000000    0x00000000
0x00F00790    0x00000000    0x00000000

Thanks for that. That data indicates that the ROM failed to find the magic number (0x41504954) at the first address in the SPI.

Can you also give the contents of memory at 0x00F006C4, which stores the last word read back by the ROM?

Is it possible for you to get scope shots of the bus activity during the boot and flashing, up until read the first word? There is something different going on in those two cases and looking at the signals might give an indication. Thanks

Jeff

Hi Jeff,

Please tell me what you understand from this:

0x00F006C4 0xFFFFFFFF 0x00000000

I've also started to think about a problem during the boot process.

Maybe it doesn't switch on time from reading the BOOT config word to reading the flash memory that sits on SPI0?

I will try to explore the boot process using a scope.

Thanks,

Ran.

Ran, that indicates it read back 0xFFFFFFFF as the first word in the SPI flash. If you look at your AIS file in a hex editor, you will see the first word is always the "magic number". After reading a valid magic number it will continue reading the next consecutive words which contain the boot image. However in your case it aborted after the first word, since it was invalid.

The next step would be to use the flashing tools to read back the first word and compare that bus activity to when the device boots on its own. You will see some difference which should indicate the issue.

Jeff