• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 97 subscribers
  • Views 496 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.

OMAP-L138 SPI driver

Kurt Jensen
Genius 5040 points
Other Parts Discussed in Thread: OMAP-L138, OMAPL138

is there any documentation for any of the code that comes with OMAP-L138_FlashAndBootUtils_2_29?  from what I see there appears to be a very useful underlying library that would actually be useful with some documentation.

for example, in spi_mem.c, the function SPI_MEM_eraseBytes() contains various vague comments that you can send paramtgers that will bulk erase OR block erase OR sector erase.  while I could read the code, some of it is more than a little obtuse. 

 

  • 0
    TI__Mastermind 27585 points

    Currently there is no documentation for this code. However we can do a better job of commenting and making the code more legible going forward, since it looks like users are finding it useful.

    As for the SPI_MEM_eraseBytes() funtion, you can pass in the number of bytes to erase, and the address to start erasing. If the start address is in the middle of a block, rather than erasing the entire block, it erases sectors until it reaches the end of the block. It will then either erase the entire next block or individual sectors based on the number of bytes left to erase. In other words, it attempts to do a bulk, block, or sector erase (in that priority) in order to speed up the erase time.

    If you want any more clarification on other parts of the code you can post here as well. Thanks for the feedback.

    Jeff

  • 0 in reply to jc-ti
    Genius 5040 points

    Thanks for your reply.  I will be working with the code starting today.

    There is another package, included with the c6748 SDK, called OMAPL138_DSP_Flash_Utility_01.00.00.01.  How does this compare to OMAP-L138_FlashAndBootUtils_2_29 described here?

  • 0 in reply to Kurt Jensen
    TI__Mastermind 27585 points

    They are very similar. One is CCS based requiring an emulator cable, and the other uses the serial port and only requires a serial connection to the EVM from a host PC. In general the serial flasher is much faster, but it is more involved if any changes need to be made, such as UART number or DDR timings.

    Jeff

  • 0 in reply to jc-ti
    Genius 5040 points

    spi-flash-writer-01.10.00.01, inside of OMAPL138_DSP_Flash_Utility_01.00.00.01, is a ccs3 project that writes the flash in the same way as SPIWriter_DSP. 

    How does this involve the serial connection?

  • 0 in reply to Kurt Jensen
    TI__Mastermind 27585 points

    The OMAPL138_DSP_Flash_Utility was the CCS based emulator approach I mentioned. The OMAP-L138_FlashAndBootUtils_2_29 is the serial flasher.

    Jeff

  • 0 in reply to jc-ti
    Genius 5040 points

    I have two utilities, one from OMAP-L138_FlashAndBootUtils_2_29.tar.gz, the other included with C6748_setupwin32_1_00_00_11.exe.

    Inside OMAP-L138_FlashAndBootUtils_2_29 is a folder called \OMAP-L138\CCS\SPIWriter.  Here is a project for an emulator based flash utility.

    Inside OMAPL138_DSP_Flash_Utility_01.00.00.01 is a folder called \spi-flash-writer-01.10.00.01\ccs3.  Here also is a project for an emulator based flash utility.

  • 0 in reply to Kurt Jensen
    Genius 5040 points

    On examining both, I cannot use either one without modification...

    SPIWriter_DSP works on my development board.  But the underlying code uses a proprietary, non-standard memory allocation scheme which includes global variable interaction and secret variables defined in the linker cmd file.

    spiflash_writer does not work on my development board - flash id code 00 00 00 - even though the readme implies that it should.  The source code contains even fewer comments which makes understanding the function calls harder.  On the other hand, the underlying code appears to use much more standard embedded C programming practice which should not require any changes.

  • 0 in reply to Kurt Jensen
    TI__Mastermind 27585 points

    Ok sorry for the confusion. I was referring to the OMAP-L138/GNU directory of the OMAP-L138_FlashAndBootUtils_2_29. It might be worth it to use this serial based flasher instead if the other two aren't working out for you.

    Jeff

  • 0 in reply to jc-ti
    Genius 5040 points

    Glad we are on the same page.  SPIWriter_DSP has been verified to prgram the flash on my development board.  I got the lead for this utility from the workshop wiki page at http://processors.wiki.ti.com/index.php/TMS320C64x+_DSP_System_Integration_Workshop_using_DSP/BIOS

    Funny thing is, the wiki page at http://processors.wiki.ti.com/index.php/Flashing_the_C6747_EVM says to use spiflash_writer_dsp.pjt which does not work on my development board.  It appears that I have a later version.  Maybe the earlier version works.

    Our device will be hooking the same flash to the SPI in the same way (which I imagine probably happens a lot).  I could write new code to program the flash for our purposes or I could use code that is already written and tested.  That is why I am trying to build a library from the source in either OMAP-L138_FlashAndBootUtils_2_29 or OMAPL138_DSP_Flash_Utility_01.00.00.01.  But one was designed poorly and the other does not work.

    Of those three choices I am trying to find the best path.  Any suggestions?