• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 99 subscribers
  • Views 4446 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.

C6748 SPI Flash programming too slow

Marcelo
Prodigy 210 points
Other Parts Discussed in Thread: OMAP-L138, TMS320C6748, CCSTUDIO, OMAPL138

Hi!

I'm working with OMAP-L138 EVM development kit from Logic by using TMS320C6748 SOM only.

My developments tools versions are as following:

CCS 3.3.83.19
CGT 6.1.10
BIOS 5.41.02.14
C6748 Device type: d800k002
OS: Windows XP SP2

I built a LED example located in:
C:\CCStudio_v3.3\boards\evmc6748_v1\tests\evm\led_pb\ccs\test_led_pb.pjt

I loaded to RAM and it worked (LEDs changed it state at expected time), but messages takes a long time in appear to stdout console.

I tried to load in flash by following next doc:

"Using the TMS320C6748/C6746/C6742 Bootloader"
focus.ti.com/lit/an/spraat2b/spraat2b.pdf

After generating bin file (I attach image of AIS gen config), I opened CCS project for spi_flash_write, located in:
C:\C6748_dsp_1_00_00_08\OMAPL138_DSP_Flash_Utility_01.00.00.01\spi-flash-writer-01.10.00.01\ccs3\spiflash_writer

After program loads, it takes me more than one hour to burn flash, and half hour to verified it contains. The program works ok (again LEDs power on and off).

I tried on another PC and it does the same.

Is a really desperating task!

Questions:

1. What am I doing wrong? Why it takes so much time?
2. How long does it takes everybody to load a simple program in SPI flash?
3. Is possible to load a program in SPI by using serial port? UART Boot Host?

I'm working in seriuos project and I really need to load a big program in SPI, and then use DRAM, so I can't allow spend so much time by trial and error.

Please help me!

Regards,

Marcelo

.

  • 0
    TI__Mastermind 27585 points

    How big is the file you are trying to flash? I have also found the CCS flashing tool to be very slow.

    The serial flasher found here (http://processors.wiki.ti.com/index.php/Serial_Boot_and_Flash_Loading_Utility_for_OMAP-L138) seems to work a lot faster. Try it out and let me know if it works better.

    Jeff

  • 0 in reply to jc-ti
    Prodigy 210 points

    Hi Jeff,

    Thanks for your reply.

    The binary LED test program has 39 KB.

    I started to work with "Serial Boot Flash utilility" that you recommend me. It's really fast tool, but I'm not sure how to use it.

    I load sft_C6748_MEM_SPI.bin in SPI Flash by using spiflash_writer and CCS.

    Then I used sfh_OMAP-L138.exe program to upload led-nor.bin example to NOR memory:


    D:\OMAP-L138_FlashAndBootUtils_2_23\OMAP-L138\GNU>sfh_OMAP-L138 -flash_noubl c:\led-nor.bin -targetType C6748 -flashType NOR
    -----------------------------------------------------
       TI Serial Flasher Host Program for OMAP-L138
       (C) 2010, Texas Instruments, Inc.
       Ver. 1.67
    -----------------------------------------------------


    Platform is Windows.
          [TYPE] Single boot image
    [BOOT IMAGE] c:\led-nor.bin
        [DEVICE] NOR

    Attempting to connect to device COM1...
    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 17280-Byte section to address 0x11800000.
    (AIS Parse): Processing command 1: 0x58535901.
    (AIS Parse): Performing Opcode Sync...
    (AIS Parse): Loading section...
    (AIS Parse): Loaded 1092-Byte section to address 0x11804380.
    (AIS Parse): Processing command 2: 0x58535901.
    (AIS Parse): Performing Opcode Sync...
    (AIS Parse): Loading section...
    (AIS Parse): Loaded 20-Byte section to address 0x118047E0.
    (AIS Parse): Processing command 3: 0x58535901.
    (AIS Parse): Performing Opcode Sync...
    (AIS Parse): Loading section...
    (AIS Parse): Loaded 16-Byte section to address 0x11804804.
    (AIS Parse): Processing command 4: 0x58535906.
    (AIS Parse): Performing Opcode Sync...
    (AIS Parse): Performing jump and close...
    (AIS Parse): AIS complete. Jump to address 0x11803B20.
    (AIS Parse): Waiting for DONE...
    (AIS Parse): Boot completed successfully.

    Waiting for SFT on the OMAP-L138...

    Flashing application c:\led-nor.bin (39596 bytes)

     100% [ ████████████████████████████████████████████████████████████ ]
                      Image data transmitted over UART.

     100% [ ████████████████████████████████████████████████████████████ ]
                       Application programming complete


    Operation completed successfully.




    The upload lasted few seconds!!!

    Then I changed S7 DIP to boot from NOR memory, but it did nothing :(


    Here are some questions to help solve the problem:


    1. Inside "Serial Boot Flash utilility" folder there are a lot of files.
    What is the purpose of these files? How to use them?

    sft_C6748_MEM_SPI.bin
    sft_C6748_NOR.bin
    sft_C6748_NAND.bin

    ubl_C6748_MEM_SPI.bin
    ubl_C6748_NOR.bin
    ubl_C6748_NAND.bin

    2. Where do you recommend burning SFT/UBL and application programs? SPI? NOR? NAND?

    3. Is really necesary erase the memory every time I upload a new program?


    Thanks a lot!

    Marcelo.

  • 0 in reply to Marcelo
    TI__Mastermind 27585 points

    1. sft_* are the uart flashing programs that get loaded on the target during serial flashing. ubl* are the UBL files in AIS format that act as secondary bootloaders for the device.

    2. Any of those will work. SPI might be the simplest since it is what the program defaults to.

    3. No, the program will erase the memory needed automatically. The erase function is only if you want to wipe the entire memory.

    To clear things up, you need to make sure your program is bootable. If you just compiled from CCS and got a .out file, you cannot simply burn it to NOR and boot. For that, you need to convert it to AIS format using the GUI found attached to the bootloader app note (http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=sprab41b). This will turn it into an AIS .bin file that can then be burned to the flash and booted from. In this case, you do not need a UBL and can simply use the -flash_noubl option. Make sure the start address and load address are correct though by setting those options in the serial flasher

    Jeff

  • 0 in reply to jc-ti
    Prodigy 210 points

    Thanks for your help.


    I forgot explain how I did before test:





    D:\OMAP-L138_FlashAndBootUtils_2_23\OMAP-L138\GNU>sfh_OMAP-L138 -flash_noubl c:\led-nor.bin -targetType C6748 -flashType NOR
    -----------------------------------------------------
       TI Serial Flasher Host Program for OMAP-L138
       (C) 2010, Texas Instruments, Inc.
       Ver. 1.67
    -----------------------------------------------------


    Platform is Windows.
          [TYPE] Single boot image
    [BOOT IMAGE] c:\led-nor.bin
        [DEVICE] NOR

    Attempting to connect to device COM1...
    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) <-- Reset with S7 DIP to boot from UART
    .
    .
    .

    (AIS Parse): Waiting for DONE...
    (AIS Parse): Boot completed successfully.

    Waiting for SFT on the OMAP-L138...  <-- Here it freezes!.  I can change S7 DIP to boot from pre-loaded SFT in SPI and continue (*)

    Flashing application c:\led-nor.bin (39596 bytes)
    .
    .
    .


    (*) It seems like C6748 is not recognized.

    Perhaps a BUG in SFH ???

    I don't know...

    Regards,
    Marcelo

  • 0 in reply to Marcelo
    Prodigy 210 points

    My problem has finally been "solved" (I think this is not the best way to load a program in SPI memory)

    I burned SFT in NAND memory, and application program in SPI.

    Here are the sequence I folowed to get it works:

    1. Open CCS project: spi-flash-writer, load in memory and run it. Then specify "dspais" and "c:\sft_C6748_NAND.bin". This loads SFT in SPI and allows access to NAND memory.

    NOTE: CCS nand-writer project didn't work for me. I always got failed access to NAND memory.

    2. Use "sfh_OMAP_L138.exe" to burn "sft_C6748_SPI_MEM.bin" in NAND. At first change S7[8:5] DIP to ON:ON:OFF:OFF (boot from UART) and then change S7[8:5] DIP to OFF:OFF:OFF:OFF (boot from SPI).

    3. Every time I want burn a new program in SPI memory I have to use "sfh_OMAP_L138.exe". A binary program (for example led_spi.bin) is generated with Aisgen utility).
    At first change S7[8:5] DIP to ON:ON:OFF:OFF (boot from UART) and then change S7[8:5] DIP to OFF:OFF:OFF:ON (boot from NAND).

    4. For normal operation, change S7[8:5] DIP to OFF:OFF:OFF:OFF (boot from SPI).


    Please feel free to send me suggestions.

    Thanks a lot again.

    Regards,
    Marcelo.

  • 0 in reply to Marcelo
    TI__Mastermind 27585 points

    Thats a very clever solution  to your problem.  I'm glad you got it somewhat working.

    It sounds like a problem  with your EVM. None of the EVMs we have here have that problem. Can you give me the serial number and revision of your SOM? 

    Jeff

  • 0 in reply to jc-ti
    TI__Mastermind 27585 points

    As a follow up, we found that for the C674x devices, a small delay is required at the start of the target program. A new version with this fix is now on the SourceForge site.

    Jeff

  • 0 in reply to jc-ti
    Prodigy 225 points

    Hi guys,

    I have the exact problem on my EVM C6748. It loads code and outputs standard output (even Message log) very slow.

    I can see that you fixed the programming part. I am just wondering that how you fixed the stdout speed issue.

    Also, Jeff, could you be more specific that a new version of what is available on which particular page of SourceForge?

    Since you guys posted this long time ago, I am not sure if you are still available, or can recall the discussion. But I'd really appreciate if you could give me some ideas of addressing this problem.

    Thank you.

    Xinwang

     

  • 0 in reply to Xinwang Zhang
    TI__Mastermind 27585 points

    The latest version can be found on this wiki:

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

    You should no have any issues with that.

    For CCS, what emulator are you using? Some may be slower than others.

    Jeff

  • 0 in reply to jc-ti
    Prodigy 225 points

    Hi Jeff,

    Thanks for your reply.

    I am using the emulator came with the EVM, XDS100.

    The speed is not normally slow. It seems has some hardware issue or wrong setup.

    I am checking on it. Sure will keep you posted.

     

  • 0 in reply to Xinwang Zhang
    Expert 1145 points

    I am having a somewhat similar problem in here? Do you have any idea how to solve it?

    http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/294867/1028949.aspx#1028949