• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 559 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Loading code to SPI Flash using OMAPL138

MikeSutton
Prodigy 30 points
Other Parts Discussed in Thread: OMAPL138, OMAP-L138

I'm trying to follow the instructions of the following wiki to program the SPI Flash connected to an OMAPL138 processor on a custom board.  It freezes at at: "Waiting for SFT on the OMAP-L138..."

http://processors.wiki.ti.com/index.php/Boot_Images_for_OMAP-L138

We have the SPI Flash connected to SPI1 of the OMAPL138.  The SPI flash we are using is the N25Q128A21.

Following is the output from the sfh utility (Perhaps it is also worth noting that I get something similar when I just try and erase the flash with the command: sfh_OMAP-L138.exe -erase -p COM5 -v):

D:\work\tmp\OMAP-L138_FlashAndBootUtils_2_40\OMAP-L138\GNU>sfh_OMAP-L138.exe -flash_noubl -p COM5 -v d:\work\tmp\ais.out
-----------------------------------------------------
TI Serial Flasher Host Program for OMAP-L138
(C) 2012, Texas Instruments, Inc.
Ver. 1.67
-----------------------------------------------------


[TYPE] Single boot image
[BOOT IMAGE] d:\work\tmp\ais.out
[TARGET] OMAPL138
[DEVICE] SPI_MEM
[SPI Block] 0


Attempting to connect to device COM5...
Press any key to end this program at any time.

(AIS Parse): Read magic word 0x41504954.
(AIS Parse): Waiting for BOOTME... (power on or reset target now)
(AIS Parse): BOOTME received!
(AIS Parse): Performing Start-Word Sync...
(AIS Parse): Performing Ping Opcode Sync...
(AIS Parse): Processing command 0: 0x58535901.
(AIS Parse): Performing Opcode Sync...
(AIS Parse): Loading section...
(AIS Parse): Loaded 9200-Byte section to address 0x80000000.
(AIS Parse): Processing command 1: 0x58535901.
(AIS Parse): Performing Opcode Sync...
(AIS Parse): Loading section...
(AIS Parse): Loaded 736-Byte section to address 0x800023F0.
(AIS Parse): Processing command 2: 0x58535906.
(AIS Parse): Performing Opcode Sync...
(AIS Parse): Performing jump and close...
(AIS Parse): AIS complete. Jump to address 0x80000000.
(AIS Parse): Waiting for DONE...
(AIS Parse): Boot completed successfully.

Waiting for SFT on the OMAP-L138...

  • 0
    Prodigy 30 points

    I'm continuing to work this and thought I'd post a bit of an update.

    1) I was able to boot load my program through the UART using the slh_OMAP-L138.exe program.  So UART stuff seems to be working just fine and AISgen must be working correctly.

    2) I can't even issue a sfh_OMAP-L138.exe -erase command.  Something isn't working correctly when talking to the SPI flash.

    I have been looking around for the code that is running on the OMAPL138 to try and understand what's happening, but I haven't found that code.  Can anyone point me towards that code?  Is that was "u-boot" is?

    Looking at the flash memory we have on the board (N25Q128A21) (here's the datasheet by the way), it says: 

    To program one data byte, two instructions are required: write enable (WREN), which is one
    byte, and a page program (PP) sequence, which consists of four bytes plus data.

    I saw a comment in the Wiki somewhere that I seem to remember saying that by default the SPI writer doesn't perform a write enable.  That's why I'd like to see to the source of the SPI writer so I can figure out exactly what it's trying to do.

  • 0 in reply to MikeSutton
    Prodigy 30 points

    Our custom board does not have any external RAM.  I think the tools might require external RAM to hold the image before it is transferred to the SPI flash.

  • 0 in reply to MikeSutton
    Intellectual 710 points

    Hi Mike,

    see http://processors.wiki.ti.com/index.php/Serial_Boot_and_Flash_Loading_Utility_for_OMAP-L138. This wiki page describes where you can get the source code of the flash loader utility and how to build it.

    MikeSutton said:

    Our custom board does not have any external RAM.  I think the tools might require external RAM to hold the image before it is transferred to the SPI flash.

    Yes, that's correct. The tool (sfh) first loads some code (sft) to the internal RAM of the SoC. This code is then executed, it initializes the external RAM, downloads the firmware image to the external RAM and flashes it to the flash memory from there (see the code in Common/sft/src/*.c). Usually only small modifications to the sft are required for custom boards (e.g. I had to change the initialization of the DDR memory controller since I use DDR2 memory instead of mobile DDR). These changes are also described on the wiki page. But as you don't have any external RAM, you'll have to do larger modifications, probably you'll have to download the firmware image in smaller chunks that fit into the internal SRAM...? Regards, Christian