Problems with SPI Flash memory configuration in based-OMAPL-137 custom board

I don't see a console attachment. I am guessing the only the first 4096 byte sector programmed. The value 4352 is the read position is the file. I am guessing that means 4352=4096+256. The 256 is a bit odd as it implied that page size is 256. From what I can see from the N25Q064A datasheet, it has 4096 byte pages, 16 pages per sector and 128 sectors. The winbond_spi_flash_params structure should be initialized to 4096,16,128. The page size of 4096 is quite large compared to the winbond parts. The code uses buffers of 512. You'll have to increase the tx and rx buffers to 4096.

First of all, sorry for the no attached file (later, I discovered the option called options)... Respect your answer, I could solve the problem adjusting a timing issue of my SPI Flash memory. First, I did these modifications that you told me, but problem did not solve, so I revised again N25Q064A datasheet looking for any solution. Besides, I saw at the emulator message console of CCS, a message with information about a timed out, erasing issues, timings or something related. In conclusion, after all, I did a little modification in a file called winbond.c (inside SPIFlash project for CCSv3.3) about the timeout in function winbond_wait_ready (see below), changing its value to 400.

//Original Code       

/* Up to 2 seconds */
        ret = winbond_wait_ready(flash, 100 * CFG_HZ);      //100 changed by 400
        if (ret < 0)
            printf("SF: Winbond page erase timed out\n");
            break;
        }

The result of that change generated a message with the following text: "Files matched". I hope the first bootloader (dsp-aspi-ais.bin) was saved correctly...

Thanks for your help!

Regards!!

Óscar

Good to know. There is some questionable code in the verification portion of main.c It treats the binary data as though it was null terminated strings. That's bad as it could write a null past the the end of the buffers and may result in false postives if the data has nulls in it. The call to strcmp() should be replaced with memcmp() and the data should be null terminated. Well...my version of the source is like that. Maybe yours has been fixed.

Hi,

Once first bootloader was saved correctly, the rest of elements (ARM-UBL and u-boot) were too without problems.There were not messages saying me " Files did not matched". After that, I though the problem would be solved, but when I changed the boot mode to SPIFLASH0 and powered on the board, a prompt u-boot did not show at the terminal... I just saw this message after every reset:

Booting with TI UBL

Device OPP (300MHz, 1.2V)

By the other hand, I tested another procedure. There is other tools to flash SPIFlash on OMAPL137 by means the "DaVinci Serial boot and  Flashing" software, allocated here http://sourceforge.net/projects/dvflashutils/files/OMAP-L137/v2.40/OMAP-L137_FlashAndBootUtils_2_40.tar.gz/download. However, the results are not the expected...

We are working in a Linux environment, so, following the instruction at the wiki page http://processors.wiki.ti.com/index.php/Serial_Boot_and_Flash_Loading_Utility_for_OMAP-L137, open a terminal and write the next commands:

sudo mono ./sfh_OMAP-L137.exe -flash_dsp dsp-spi-ais.bin ubl-spi.bin u-boot.bin

I could see the BOOTME prompt, selecting UART2 mode. Moreover, the three bootloaders have been copied from the PSP Release directory (http://processors.wiki.ti.com/index.php/DaVinci_%28ARM9%29_PSP_Releases#AM17x.2FOMAP-L137.2FDA830), except for the u-boot.bin, because from the EVM OMAPL137 SupportHome website (http://support.spectrumdigital.com/boards/evmomapl137/revg/) recommend using a updated u-boot for newer SPI chips. As a consequence, I used the first two bootloaders from the PSP release and the last from SpectrumDigital. The result is attached... At the last line (message--> Waiting for SFT on the OMAPL137), process is freezed... Maybe, use of different SPI chips affects to the others bootloaders (dsp-spi-ais.bin and ubl-spi.bin) and its rebuilding is needed... I am a little confused...

Any suggestion or advise in order to try fixing the problem??

Thanks in advance!

Óscar

I've never used UART boot or the serial programmers. With SPI Flash boot, I looks like the DSPUBL or ARMUBL has successfully loaded. DSPUBL will load the ARMUBL. The ARMUBL wil configured DRAM and load U-boot. My guess is that the DRAM is not configured properly or not connected properly.

Thanks for your answer Norman, but I continue struggling...

Respect to the first procedure showed at the previous post (use the spi flash writer at CCSv3.3 and save the three bootoaders), do you have (or anyone) any suggestion or advice?? Remember I am using a based-OMAPL137 custom board.. By the other hand, EVM board writes the same two messages as well (see below) but after that, it continues with the u-boot prompt ...

messages:

Booting with TI UBL

Device OPP (300MHz, 1.2V)

Besides, the major difference between EVM board and my custom board is the SPIFlash Memory. At the EVM, it uses a  32-Mbit memory whereas at the custom board, size is increased up to 64-Mbit. I have done changes in the code of SPIFlash project like modify the ID device and parameters related with the erase time, because the "my SPIFlash chip" is slower than EVM's SPIFlash chip.. But this changes have just been done in the project of SPI Flash writer. I have seen the code of the three bootloades (dsp-spi-ais.bin, ubl-spi.bin and u-boot) and I have found lots of contents related with SPI.

Therefore, I wonder if I have to modify code of bootloaders because of the use of different SPIFlash chip?? Advises or suggestion please!!

Thanks in advance!

Óscar

Hi Oscar,

Did you try using the same binaries from the PSP release suggested in our other thread? It looks like you are having a similar issue with your custom board.

http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/253670/887662.aspx#887662

Thanks,

Clinton

Hi Oscar,

I noticed you did mention in an earlier post that you were using the PSP suggested in our other thread. I would recommend using the u-boot binary out of that location as well and let us know what your results are.

Thanks,

Clinton

Hi Clinton,

Yes, I did the same procedure with the same binaries from the PSP that you suggested me earlier, but it did not work... I need to know (if it is possible) if I have to modify the code belongs to the other bootloaders and its contents related with the SPI.

Thanks in advance!

Óscar

I think the SPI Flash is working properly. The difference in timing matters only in programming the flash. Reading from the flash looks good. My line of reasoning.

The ROM bootloader will load the DSPUBL(dsp-spi-ais.bin) into static RAM. Since we see the "Booting with TI UBL" that is printed out by the ARMUBL you can assume that the ROM bootloader can read from SPI flash properly.

The DSPUBL will load the ARMUBL(ubl-spi.bin) into static RAM. Since we see the "Booting with TI UBL" that is printed out by the ARMUBL you can assume that the DSPUBLr can read from SPI flash properly.

The ARMUBL will configure SDRAM and load u-boot into SDRAM. It will configure SDRAM, test SDRAM and copy from SPI Flash to SDRAM. The test could fail with some sort of exception. The u-boot in SDRAM could be corrupt. Execution of bad code could also result in an exception. It might possible it is hanging when configuring some peripheral or clock.

Try adding a lot more debugging printing in the ARMUBL to see where it fails. The DSPUBL and ARMUBL should not need any SPI timiing tweaks. U-boot might but only if you use U-Boot to program SPI flash.

Tired to debug and degug the source code of the OMAP's bootloaders, I decided to use the EVMOMAPL137 SPI Programmer, which contains the project for the SPI Flash Programmer. it is located in the following url: http://support.spectrumdigital.com/boards/evmomapl137/revg/files/EVMOMAPL137_SPI_PROGRAMMER.zip.

For  EVM board, the three bootloaders are written and checked without problems on SPI Flash memory, everything ok. I have debugged source code by means Code Composer Studio v5 for Linux, going step by step through the functions and the result seems good. Each bootloader ends with the folloowing message : "Files matched".

However, when I changed the boot mode ( pines configuration to SPIO boot--> 0101x), I just see two lines at the serial  port terminal. (see below). This information was mentioned in a earlier post...

Booting with TI UBL

OPP--> 1,2V and 300MHz

And there is not any uboot prompt... Before that, I was testing this procedure with the custom board, and I though this board could have any hardware failure or something like that, but now, making these operations in EVM board, I don’t understand what is going on... Any suggestion or advise it would be appreciated. Thanks in advance

Regards

Óscar

Just to confirm, you are using the original bootloaders on the EVM. The SPI versions and not the NAND versions? I can't think of anything else. You should unverify my post above. Unverified threads attract more attention.

Thanks for your quick answer.

Both things you suggested me are correct. I am using the original bootloaders and the SPI versions. What else can I do?? Thanks in advance

Edited:

Another procedure tested right now has been with the OMAP-L137_FlashAndBootUtils_2_40 tools. This package contains a SPIFlash Project. It is a little differences than the other (DaVinci-PSP-SDK-03.20.00.14). This information (see below) is obtained from console:

------------------------------------------------------------------------------------

[C674X_0] Starting OMAP-L137 SPIWriter.
Will you be writing a UBL image? (Y or y)
Answer:y
Enter the binary AIS UBL file name (enter 'none' to skip):
Answer:none
Enter the application file name (enter 'none' to skip):
Answer:/home/gtsc/Descargas/DaVinci-PSP-SDK-03.20.00.14/images/u-boot/omapl1x7/u-boot.bin
    INFO: File read complete.
Enter the app image load address (in hex):
Answer:0x8000
Enter the app image entry point address (in hex):
Answer:0xC1080000
Doing block erase.Doing block erase.Doing block erase.    SPI boot preparation was successful!

------------------------------------------------------------------------------------

Now, this application only allows two entries, I mean, it demands a binary AIS UBL file and an application file name. At the another application (Davinci..), it demands three bootloader files ( DSP UBL, ARM UBL y uboot). In this case, everything seems clear although does not work.

What files are needed in the first application?What is the binary AIS UBL file? Is it pre-built in any folder of package? And what is the application file? Is it uboot?

Sorry for so many questions but I need to restore EVM board as soon as possible.

Regards

Óscar

Nothing that will help. Just commenting. The dsp_spi_flash_writer project at Spectrum Digital and in the PSP prompts for one file at a time:
 Enter the image type (one of "dspais" "armubl" "uboot" "other")
 Enter the File Name
I have to run the project 3 times. Once for each image

dspais
dsp-spi-ais.bin

armubl
ubl-spi.bin

uboot
u-boot.bin

I haven't used OMAP-L137_FlashAndBootUtils_2_40 tools. This seems to behave like the serial port programmers. There are several and each takes slightly different arguments. Perhaps somebody ported the UART code to JTAG operation.

Hi Norman,

Finally, I could solve the awful problem. After rebuilding the SFH_OMAPL137.exe tool from OMAP-L137_FlashAndBootUtils_2_40 package, my custom board did not work. So, I decided to flash a new custom board, equal than the first, but without any tests. And flashing process worked using the first two bootloaders from the DaVinci-PSP-SDK-03.20.00.14 and the last bootoader from http://support.spectrumdigital.com/boards/evmomapl137/revg/files/120709-U-boot-SPIUpdate.zip, a uboot version that recognizes newer SPI Flash chips (remember that I use a slightly different SPI FLASH chip than the EVM SPI FLASH chip). Making these operations, I could see the uboot prompt!! However, life is not perfect and I have new problems...

Now, I can see the uboot prompt, and type commands like printenv, setenv and so on but when I save these changes by means saveenv, following mesage is printed:

Failed to initialize SPI flash at 0:0

In order to solve that problem, I select the SPI 0FLASH 0 interface by means sf probe , but the result is the same... An interesting option it would be know to compile the uboot with debugging options to detect fails and fix these mistakes. Any suggestion for that??

The description at the spectrumdigital website fixes this problem theoretically ( read below) but it does not work so far..

The original U-Boot shipped with this board did not recognize newer SPI Flash chips and could not save U-Boot environment variables to SPI Flash in certain situations. This version of U-Boot addresses those issues and ships with newer revisions of the EVM. (http://support.spectrumdigital.com/boards/evmomapl137/revg/)

Maybe I have to change the SPI FLASH ID in any file of uboot package? Something like 0x3016 by 0x (my SPIFLASH ID)??

The most interesting thing for me right now is to enable the debugging option for uboot! I need advises!

Thanks in advance!

Regards!

Óscar

Hi Norman,

Your advise was perfect! I could solve the compatibility problem between SP FLASH chip with new uboot (u-boot-bc5fd908d976cfd898e8cbb591e7220ddc8a684a.tar.gz) downloaded from http://git.denx.de/?p=u-boot.git;a=summary. I had to rebuild the uboot for my custom board by means the following commands:

make distclean ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-

make da830evm ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-

Also, I defined a new order at the /include/configs/da830evm.h called #define CONFIG_SPI_FLASH_STMICRO and I undefined #define CONFIG_SPI_FLASH_WINBOND in order to recognize my SPI FLASH custom board ID. Everything was perfect! Thanks for your advise Norman again.

Regards

Óscar