Forums

Sandeep,

You have a new board and have made changes to the software examples. So many changes at one time make remote debug difficult. This is one reason that many users prefer to use the exact same components as are on our DSK boards. But that is not always possible.

The error message is telling you that there is something wrong in the data seen by the bootloader when it tries to read the contents of the SPI Flash. So you must narrow down to which AIS keyword is not correct.

My advice is to read the entire SPI back, maybe using a small modification to your SpiWriter.out program for verification. Then reduce the data file manually to test a reduced load image. Maybe create a very small load image and see if you can load just that.

Also, it would make sense to re-examine the changes you made in device_spi.c, and try changing some of the values in there to see if you may have changed something so that the image would not work.

Regards,
RandyP

Hello Randy,

The image that we are trying to load is 28kb only.

From the debug Gel file I got the following info:

C674X_0: GEL Output: ---------------------------------------------

C674X_0: GEL Output: |               BOOTROM Info                |

C674X_0: GEL Output: ---------------------------------------------

C674X_0: GEL Output: ROM ID: d800k006

C674X_0: GEL Output: Silicon Revision 2.0

C674X_0: GEL Output: Boot pins: 10

C674X_0: GEL Output: Boot Mode: SPI0 Flash

C674X_0: GEL Output:

ROM Status Code: 0x00000009

Description:C674X_0: GEL Output: Invalid AIS keyword

C674X_0: GEL Output:

Program Counter (PC) = 0x800044E0

C674X_0: GEL Output:

C674X_0: GEL Output: ---------------------------------------------

C674X_0: GEL Output: |              Clock Information             |

C674X_0: GEL Output: ---------------------------------------------

C674X_0: GEL Output:

C674X_0: GEL Output: PLLs configured to utilize crystal.

C674X_0: GEL Output: ASYNC3 = PLL0_SYSCLK2

C674X_0: GEL Output:

C674X_0: GEL Output: NOTE:  All clock frequencies in following PLL sections are based

C674X_0: GEL Output: off OSCIN = 24 MHz.  If that value does not match your hardware

C674X_0: GEL Output: you should change the #define in the top of the gel file, save it,

C674X_0: GEL Output: and then reload.

I checked out the gpio.BIN in Hex format. The Start address has the following value 54 49 50 41 ... Is it correct considering that the First few bytes represent the magic number of the Flash. In our case the flash used is M25P64. Can you draw any conclusion out of this?

What does this ROM Status Code 0x00000009 Signify?

Can there be any Hardware Problem which we have overlooked? Few have mentioned about similar problem and said the problem lies between the reset signal and the boot_disable signal. Can you look into our Schematic and ascertain its correctness? The Schematic is attached along with this mail.2260.digital board.pdf

Hello Randy,

I connected UART1of TI processor  to the RS323 port CPU to see the status & error report during Boot. I got the following Message :

AIS Parse): Waiting for BOOTME... (power on or reset target now)
(Serial Port): Read error! (The operation has timed out.)
(AIS Parse): Read invalid BOOTME string.
(AIS Parse): Boot aborted.
(Serial Port): Closing COM1.

Sandy,

The ROM is hard coded to use certain pins of the SPI peripheral for boot, and these are documented in the boot loader app note.  For SPI boot, the CS pin is used and the peripheral operates in 4-pin mode (the other pins are of course CLK, SIMO, and SOMI). The EN pin is not used in the SPI boot mode setup.

The ROM cannot be changed to use the EN pin.  We cannot envision a software solution to this.  Some kind of hardware change will be required in your setup.

Regards,

Rahul

If you do rev the PCB to fix the hardware, make sure you are aware of the new requirements for the BOOT pins.  See:   C6748 SPI1 FLASH Boot failure on Custom PCB.  Boot pins all high.

- Dean

Hi Dean

The boot pin issue that you struggled with is now a published errata

http://www.ti.com/lit/er/sprz303f/sprz303f.pdf  (2.1.23)

Regards

Mukul

Hi Sandy,

The bootloader doc mentions that the appropriate pin (SPI0_SCS[0] or SPI1_SCS[0]) must be connected to the external SPI device. It doesn't mention about connecting SPIx_ENA pin to CS.

Since you have connected SPIx_ENA pin instead SPIx_SCS to CS of flash. I would recommend to try once making flash CS pin ground so that flash get selected and work in 3pin mode.

Mukul/Dean,

Correct me if I am wrong, does the errata mentioned related to same error?

Thanks!!
Regards
Sathish

Hello Satish,

We have already tried this out. Infact we have cut the track and pulled the 'CS' line permanently. Still it was not working. We could see clock signal in the 'CLK' line (burst of 8 bits/rising & falling). Still the Processor was not booting.Then we looked into the Data sheet of the 'M25P64'  and we found the following sentece

'After Power-up, a falling edge on Chip Select (S) is required prior to the start of any instruction [Page number 9 of data sheet M25P64-VME6TG]'.

So, 'CS' line need a high to low transition before the start of instruction at power ON {because Flash sees the falling edge}.Hence we concluded that pulling the CS line permanently is a big mistake.

 Errata speaks about the logic line of the Boot pins & etc. For our hardware those line are working correctly and we have verified it by using the DEBUG.gel file.

Regards,

Sandeep.

Sandeep,

Yes, what you noticed is correct. Most Master-Slave SPI Flash interface configurations would expect a high to low transition on CS before communication begins. With the hardware change of using EN instead of CS, the SPI writer can be changed to write the boot image on the flash because it is a modifiable code/configuraton that runs from RAM. But while booting the device, the processor is running the fixed rbl code in its ROM. The ROM code has the processor-SPI Flash slave boot configured in 4 pin mode using the CS. This forces the transition from high to low only on the CS of the processor while booting from SPI flash and not on the enable pin. We have documented all these hard restrictions in chapter 9 of the bootloader app note.

Unfortunately we do not forsee, a change in the software or a simple workaround to fix this issue. You need to route the upp_SPI_SCS[0] to the SPI_SCS[0] to be able to boot over SPI flash.

Regards,

Rahul