OMAP-L138 Booting from SPI ATMEL

Hello, I am using a custom board with OMAP-L138 And SPI flash of ATMEL AT45DB321D. I flashed the SPI using CCS4 with spi-flash-writer( I had to add support for ATMEL since the spi-flash-writer 3.20.00.XX does not include support for atmel). Anyway, I get that the application succeed in reading with the text "File Match". I flashed first arm-spi-ais.bin - "armais" file, but after reseting in mode booting from SPI1 flash (0x0C in boot configuration register), I get no printing at all in UART. I tried to change page size from 528 to 512, and flashed again the armais file but still nothing... Can it be that OMAP cannot boot from ATMEL, or is there anything else wrong in my configuration ? I thank you for your help, Ran Shalit
  • Hi Ran Shalit,

    I hope you have interfaced the SPI Flash according to the user guide which is avaialbale at the following URL

    http://focus.ti.com/dsp/docs/litabsmultiplefilelist.tsp?sectionId=3&tabId=409&literatureNumber=sprab41c&docCategoryId=1&familyId=1621

    Looks the constraints specified in above user guide are met by your device,  24-Bit addr and support a read command value of (0x03).

    I hope you are not using any chip select other than CS0.

    Regards,

    GSR

  • In reply to 1258021:

    I agree with 1258021(aka GSR). The read command (0x03) is supported by the device as "Continuous Array Read (Low Frequency Mode)".  The address is 22 bits in 512 byte mode (which you will have to use, as the addressing scheme in 528 byte mode is not compatible).

    Since this appears to be a custom board, you may also need to change some aspects of the UBL. In particular, I thinking that if you have an oscillator or crystal that works at a different frequency, the UBL included will not setup the UART as needed for 1152008n1 operation.

    Finally, if you have the JTAG connection, you can try using the debug GEL files to see if you can get more info about what is going on during a failed boot.

    Regards, Daniel

  • In reply to Daniel Allred:

    Hi Dandiel & GSR,

    Thank you for your ideas.

    atmel_datasheet.pdf
  • In reply to Daniel Allred:

    Hi Daniel & GSR,

    Thank you for your ideas.

    • the continous read command (0x3) is supported by AT45DB321D.
    • I see that for 528 page it uses 23 bits, and for 512 page it uses 22 bits:

     "Buffer addressing for the DataFlash standard page size (528 bytes) is referenced in the
    datasheet using the terminology BFA9 - BFA0 to denote the 10 address bits required to designate
    a byte address within a buffer. Main memory addressing is referenced using the
    terminology PA12 - PA0 and BA9 - BA0, where PA12 - PA0 denotes the 13 address bits
    required to designate a page address and BA9 - BA0 denotes the 10 address bits required to
    designate a byte address within the page.
    For “Power of 2” binary page size (512 bytes) the Buffer addressing is referenced in the
    datasheet using the conventional terminology BFA8 - BFA0 to denote the 9 address bits
    required to designate a byte address within a buffer. Main memory addressing is referenced
    using the terminology A21 - A0, where A21 - A9 denotes the 13 address bits required to designate
    a page address and A8 - A0 denotes the 9 address bits required to designate a byte
    address within a page.

    On my previous trials, I configured the flash for 512 page size, and flash the UBL again,
    but still I did not see any characters in the UART when booting from SPI Flash.

    • what did you mean about changing some aspects of the UBL ? does the UBL fits itslef only to the OMAP-L138 EVM? how do I change the UBL and what should I change in it?
    • I saw in the CC studio that the boot configuration register is set for booting from spi flash (0xc) , is there something else maybe I should watch in particular on the failed boot.

    I have attached the atmel datasheet in the previous post (sorry for sending the previous message not complete).

    >Interesting thing to Note here is that the flash program read phase (after the writing) verifies that writing is successful , so does not that mean that the flashing was OK ?

    Thank you !!!

    Ran

  • In reply to 1258021:

    Hello GSR,

    Thank you for your support,
    I see that the atmel uses 22 bit address for 512 page, and 23-bit for 528 address, Does it mean that there is problem here with the 24-bit addressing constrain ?
    I have attched the datasheet in the previous message.

    >Interesting thing to Note here is that the flash program read phase (after the writing) verifies that writing is successful , so does not that mean that the flashing was OK ?

    Thank you !!!

    Ran

  • In reply to Ran Shalit:

    ran shalit

    Hello GSR,

    Thank you for your support,
    I see that the atmel uses 22 bit address for 512 page, and 23-bit for 528 address, Does it mean that there is problem here with the 24-bit addressing constrain ?
    I have attched the datasheet in the previous message.

    The ROM boot loader will linearly increment the address (unless you turn on sequential read, in which case a single read command and address is sent and then the memory device is just expected to spit out data while incrementing on its own). In any case, the ROM boot loader does not know anything about pages and splitting the address bits between pages and blocks, so the 528 byte mode won't work. It may work in sequential read mode because all of the upper address bits during the reads from the start of the memory will be zero, but the device data sheet can specify what happens in that case.

    Regards, Daniel

  • In reply to Daniel Allred:

    Hi Daniel,

    So does it mean that Although it is 22 bit address for 512 page, and not 24 bits, I can still use it?
    I see that the spi-flash-writer, verifies that file match, which means (if I'm correct) that the UBL is flashed correctly in the SPI flash.  
    But after setting 512 page configuration, and getting "file match" for the UBL flash, there is still nothing in the UART.
    Does it mean that the UBL does not fit my configuration. What steps you suggest me to take ?

    Regards,

    Ran

    spi-flash-writer/main.c

    .....

      while(!feof(fPtr))
        {
      unsigned int nbytes;

         if(!feof(fPtr)) {
       nbytes = fread(tx, 1, page_size, fPtr);
      }  
      tx[nbytes] = '\0';

      flash->read (flash, i * page_size, page_size, (Uint8 *)rx);
            rx[nbytes] = '\0';
      if(strcmp((const char *)rx,(const char *)tx)!= 0) {
       printf("Files did not match @ %d\n", ftell(fPtr));
       goto finish;
      }
      i++;
        }

     printf("Files matched \n");

     

  • In reply to Ran Shalit:

    The ROM will always send out 24 address bits.  This matches with what this Atmel device expects, so there is no issue (only 22 of the bits will mean anything to the Atmel device and unless the ROM tries to read past the end of the flash, those upper two bits will always be zero anyways).

    Please use the debug gel file I mentioned earlier to try and get the status of the ROM boot process.

    Also, have you followed the directions in the section 13 of the datasheet to permanently configure the device for 512 byte (power of two) page size? Is that what you mean when you say "setting 512 page configuration"?

    Regards, Daniel

  • In reply to Daniel Allred:

    Yes, I've configured the device to permanently use 512 byte page (and reset the system afterwards), and the flashed the UBL again (I was able to see that the ATMEL configuration was changed to 512 bytes page, becuase it prints the page size in the probing function).

    I use the LogicPD Gel file (same as in the EVM), meanwhile without any changes. What did you mean about the boot process state ? should I see where the PC is and try to understand what functions were fetched from the SPI memory?

    Do I need to create new UBL file before flashing it into the SPI flash or does the UBL file should match any configuration?

    Regards,

    Ran

  • In reply to Ran Shalit:

    ran shalit

    I use the LogicPD Gel file (same as in the EVM), meanwhile without any changes. What did you mean about the boot process state ? should I see where the PC is and try to understand what functions were fetched from the SPI memory?

    See the link I mentioned earlier: http://processors.wiki.ti.com/index.php/OMAP-L1x_Debug_Gel_Files

    If the boot fails, you can use this file to get some info from the device about what happened.

    Regards, Daniel