• State
  • Locked Locked
  • Replies 24 replies
  • Subscribers 98 subscribers
  • Views 3581 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 Flash startup time slow

Yoel Motola
Expert 1470 points

Other Parts Discussed in Thread: OMAP-L137, SYSBIOS, OMAP-L138, OMAPL138

Hello All,

I am using LogicPD Omap L138 SOM on a custom board, SysBios 6.34.2.18, XDCTools 3.23.5.61, StarterWare 1.10.03.03.

I Used AIS generator to create the file to flash the chip using the sfh tool.

Everything works well except that from the moment I power up the board to the moment the application starts running, it takes 15 seconds.

My AIS file is 2.5MB (mostly openCV libs).

Thanks,

Yoel

  • 0
    Guru 26430 points

    Assuming the majority of time is transferring from SPI Flash to RAM, the SPI clock speed most determines the speed of the transfer. What clock speed did you specify in the AISGEN? I think I remember my OMAP-L137 defaulted to 30Mhz in AISGEN. On the my LCDK-C6748, the AISGEN default was much lower but I bumping it up appears to work. It did not crash. Can you break up the bootup time into specific parts?

  • 0 in reply to Norman Wong
    Expert 1470 points

    Hey Norman,

    Thanks for the quick reply!

    I use SPI Clock 20 (18.75MHz), Do you what is the maximum freq I can use? Does this effect other issues after bootup?

    How do you suggest I break up the bootup time? it takes forever before my code even starts running (I can determine it by an I\O led on my board).

    Yoel

  • 0 in reply to Yoel Motola
    Guru 26430 points

    Check the SPI Flash Datasheet for maximum SPI clock frequency. The typical Winbond chips is 35Mhz. I think your SYSBIOS SPI driver will initialize the SPI clock again anyways. Same with the source clocks.

    I am more familiar with ROMBL, DSPUBL, ARMUBL, U-boot and Linux. Each printed something to it was easy to time each portion. In your case, you probably only have ROMBL and SYSBIOS with APP. Timing the SYSBIOS components might be difficult if nothing is printed. There might be a lot of SYSBIOS init before your LED code runs.

  • 0
    TI__Mastermind 43955 points

    Hi Yoel,

    There is one more option to flash the image other than sfh utility. That is using SPI writer which is available as a CCS project along with the source code. As this method is via CCS, you can use debug option and check where it takes more time.

    Details on SPI writer project:

    MCSDk package :

    path after installation: "..\mcsdk_1_01_00_01\host-tools\OMAP-L138_FlashAndBootUtils_2.40\OMAP-L138\CCS\SPIWriter"

     

    Regards,

    Shankari

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

    Please click the Verify Answer button on this post if it answers your question.
    --------------------------------------------------------------------------------------------------------

  • 0 in reply to Shankari G
    Expert 1470 points

    Dear Shankari,

    I'm having trouble with the bootup time (the time it takes the code to go from flash to RAM), not the time it takes to flash the image.

    Furthermore, I tried to use this project and the program never ends, only with small files and even that takes forever (mine is 2.5mb).

    Yoel

  • 0 in reply to Yoel Motola
    TI__Guru** 116100 points

    Hi,

    As Norman suggested,

    Have you tried to increase the freq of SPI through AISgen tool?

    How about the results?

    I believe that you have ported (combined) starterware code into SYSBIOS.

    Please correct me if I'm wrong.

    I'm having trouble with the bootup time (the time it takes the code to go from flash to RAM), not the time it takes to flash the image.

    What type of RAM are you using to run the code ?

    Ex:

    DDR2, L3 RAM(shared), L1/L2 RAM etc.,

    Sorry, I knew that code size was ~2.5MB, So you might be run the code into DDR2 only.

    After reducing the size, You can try to run the app on different memories.

    Furthermore, I tried to use this project and the program never ends, only with small files and even that takes forever (mine is 2.5mb).

    Do you have any DEBUG print in your code?

    What are the peripherals you are using in your project?

    Ex: GPIO, SPI, EDMA etc.,

    To decrease the code size, You can use "PSC enable" option to enable peripherals through PSC number in AISgen tool than using "PSCModuleControl" APIs in your project.

    Please refer the following links,

    http://processors.wiki.ti.com/index.php/C2000_Flash_Common_Issues/FAQs#Code_Runs_Slower_in_Flash_than_RAM

    http://e2e.ti.com/support/embedded/tirtos/f/355/p/274403/966203.aspx

    http://processors.wiki.ti.com/index.php/SYS/BIOS_FAQs#1_Making_a_debug-able_Custom_SYS.2FBIOS_Library

  • 0 in reply to Titusrathinaraj Stalin
    Expert 1470 points

    Hey Titus,

    Well, your reply raised some questions I never thought about asking, so I will need some help understanding the flashing process.

    1. Norman suggestion (Thanks Norman by the way) seemed like a sure thing but it didn't help to bootup the system (I raised the freq from 20Mhz to 50Mhz which is the AISGen max), donno why...

    2. I did combine starterware with SYS\Bios.

    3. I load the code to the DDR.

    4. I don't use DEBUG prints (or did you refer to the flash programming project?).

    5. I enable the PSC in the AIS file but also in my code (I remember that at the begining, it didn't work if it was only in the AIS file, maybe you can think of a reason why), anyway, this is a fraction of the code...

    Now here are some points:

    A. My code is 2.5MB (ARM+DSP), most of the code is OpenCV libraries for the DSP (The code for the ARM only is 170KB), so I guess I can load it to a faster memory but I don't know how to load the DSP code later.

    B. I direct the DSP to L2 RAM (.text:_c_int00: align=1024 > 0x11800000) but there isn't really room for the extra 2+MB there, how does the code know to go to the DDR? (The program is running).

    So basically, I understand that I need to split the loading of the code to the ARM and the DSP (after the system is up), will that be faster? Is there a tutorial on how it is being done (If it can be done at all...)?

    Thanks,

    Yoel

  • 0 in reply to Yoel Motola
    TI__Guru** 116100 points

    Hi,

    5. I enable the PSC in the AIS file but also in my code (I remember that at the begining, it didn't work if it was only in the AIS file, maybe you can think of a reason why), anyway, this is a fraction of the code...

    Remove all the PSC API's from code and build then check the size of "out" file generated by CCS.

    Please update the results.

    A. My code is 2.5MB (ARM+DSP), most of the code is OpenCV libraries for the DSP (The code for the ARM only is 170KB), so I guess I can load it to a faster memory but I don't know how to load the DSP code later.

    B. I direct the DSP to L2 RAM (.text:_c_int00: align=1024 > 0x11800000) but there isn't really room for the extra 2+MB there, how does the code know to go to the DDR? (The program is running).

    So basically, I understand that I need to split the loading of the code to the ARM and the DSP (after the system is up), will that be faster? Is there a tutorial on how it is being done (If it can be done at all...)?

    Please refer the TI wiki page.

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

  • 0 in reply to Titusrathinaraj Stalin
    Expert 1470 points

    Hi Titus,

    The difference is 1KB.

    I can't understand fro this wiki page how to load the DSP binaries separately from the ARM binaries (right now the AISGen combines them together) and how can I load them after bootup.

    Is the a way to separate the large chunk of code from the bootup process?

    Yoel

  • 0 in reply to Yoel Motola
    TI__Guru** 116100 points

    Hi,

    You can flash ARM and DSP binaries separately through "-flash" option instead using "-flash_noubl"

  • 0 in reply to Yoel Motola
    Guru 26430 points

    On second thought, the SPI transfer times do not make sense. Assuming 20Mhz SPI clock. The rate would be 20Mhz/8 = 2.5MB/s = 2.38MiB/s. To transfer 2.5MB should take 1.05s. There will be some overhead but not 15s. I hope I got the math right.

    Maybe scope out the SPI clock to see what is the frequency.  Maybe you got some sort or clocking problem. At the same time watch when the SPI clock pulses during boot. Time the how long you get SPI clocks. When they end, the ROMBL should hand over to your ARM code.

    Do you get the same startup times when debugging using JTAG?

  • 0 in reply to Norman Wong
    Expert 1470 points

    Hey Norman and Titus,

    To answer your questions:

    1. I did check the spi clk, it is 50Mhz (20ns).

    2. In debug, it takes about 80 seconds to load the code to the DSP but the .out file is 15.5MB (The AISGen compress the files somehow, maybe it's only binarization, 15.5/8~=2), the code starts running immediately.

    More questions:

    A. Will splitting the AIS file to 2 binaries make the ARM start running or will it wait for the DSP load?

    B. I direct the DSP to L2 RAM (.text:_c_int00: align=1024 > 0x11800000) but there isn't really room for the extra 2+MB there, how does the code know to go to the DDR? (The program is running) - I can't find the answer to that in the link you sent.

    Yoel

  • 0 in reply to Yoel Motola
    Guru 26430 points

    For how long do you see SPI clock pulses? At 50Mhz, I'd expect that after 1s that the SPI clock would be idle. If that is the case, the slow down is not due to SPI transfer speed.

    Is there anyway to tell when the ARM is up? The DSP? I've never AIS loaded both ARM and DSP before. I would assume that both processors start running but I am guessing. A race condition maybe?

    A remote possibility. Since the code runs immediately in JTAG debug this sort of implies to me that there is a lot of variable initialization. There is possibility that in JTAG debug, the initialization is done during the 80s download, ie the download contains the initialized values. This includes zero filled areas. In standalone, the variables might be initialized by code. Thta code might taking of some time. Are you compiling with ram_model or rom_model?

    Another possibility is that you have GEL script for debug and init code for standalone. You would have to be pretty determined to setup up this sort of arrangement. Does you GEL script have anything in it? At this point, it should be empty.

  • 0 in reply to Norman Wong
    Expert 1470 points

    I can see the SPI clock pulses for about 10 seconds that's 2 seconds before I can see that the ARM starts running (I have leds that are initially on but when GPIO is configured they are swiched off, That process happens after 11-12 seconds.

    The code runs in rom_model can't change it for some reason.

    I do use GEL scripts for debug but in standalone, everything is configured by the AIS gen tool. The Gel file configs the DDR and clocks mostly.

    Maybe I need to seperate the two binaries, do you know if I need UBL for the arm or just flash the ais file with ARM project only?

  • 0 in reply to Yoel Motola
    TI__Guru** 116100 points

    Hi Yoel,

    Maybe I need to seperate the two binaries, do you know if I need UBL for the arm or just flash the ais file with ARM project only?


    We need ARM bootloader to wakeup the DSP (For running DSP app alone).

  • 0 in reply to Titusrathinaraj Stalin
    Expert 1470 points

    Hi Titus,

    I don't really understand all that process with the AIS gen and the bootloader.

    If I use it only with ARM project (not using the + option in the ARM application file textbox), doesn't it already contains the bootloader?

    The ARM code wakes up the DSP so if I make AIS file for the ARM and flash it using "-flash" command and do am AIS file for the DSP and use the "-flash_dsp" command, will it work? Is this a correct process if I want to seperate the two?

  • 0 in reply to Yoel Motola
    TI__Guru** 116100 points

    Hi Yoel,

    OMAPL138 device is ARM boot device ie ARM wakeup first and then DSP,

    OMAPL137 device is DSP boot device ie DSP wakeup first and then ARM,

    so, If you want to run ARM app on OMAPL138, you can run directly also you don't want any bootloader,

    but if you want to run DSP app on OMAPL138 then you need to ARM bootloader here to wakeup the DSP and we can run DSP app through "entry point" mentioning in ARM bootloader.

    It is reverse for OMAPL137 device, It needs DSP bootloader to run ARM app and we can DSP app directly.

    The ARM code wakes up the DSP so if I make AIS file for the ARM and flash it using "-flash" command and do am AIS file for the DSP and use the "-flash_dsp" command, will it work? Is this a correct process if I want to seperate the two?

    In my understanding, The same results will be the same if you flash the both files separately or combined.

    Sorry for asking the same; Could you please provide your requirement?

    ie What you are trying to do for fixing the slow process & narrow down the problem.

  • 0 in reply to Titusrathinaraj Stalin
    Expert 1470 points

    Hey Titus,

    My requirements are as follows:

    I have a program running on the ARM core which does all the interfacing with the outer world (uart, spi etc.), The ARM core sends data to the DSP for processing.
    So I have one project (light) for the ARM core and one project (heavy with opencv libs) for the DSP core.

    I am trying to minimize the bootup time of the system. I didn't have much success so I'm searching for ways to bring up the ARM core and let the program start running (so I can give some notifications or any user interface) and then load the DSP core.

    The overall bootup time is still critical.

    Hope I made myself clear.

  • 0 in reply to Yoel Motola
    Guru 26430 points

    I am guessing that during the 10 seconds fo SPI clock activity that the clock is not on continously for that 10 seconds. At 50Mhz, I would expect less than 1 second of actual clock spread out over 10 seconds. So in that 10 seconds, do you see 9 seconds of idleness? In AISGEN, what is your PLL0? CPU clock? CRC Enabled?

    I think rom_model means to initialize in place. That should be faster than the ram_model which would copy from flash to RAM and then RAM to RAM.

    I think using AISGEN to load the ARM opens up a lot of work that you might not want to do at this point

    - The ARM code would need to read the DSP image from SPI flash and transfer it to shared DRAM. You would need to decide the format of the binary image. That is not a trivial as it sounds. Choices usually resolve into raw binary, AIS, and custom. The custom method would require writing your own wrapper tool. The AIS method requires you to port the AIS parser (source is in C#).

    - In standalone, you probably don't want the ARM to load the DSP. You'd need some way to conditionally run the loader. Adds more complication and risk.

  • 0 in reply to Norman Wong
    Expert 1470 points

    The spi clock seems to give 8 pulses (160ns long together) every 3us, but it spreads around those 10seconds.

    Here is the parameters from the AISGEN config file:

    Boot Mode=SPI1 Flash
Boot Speed=50
Flash Width=0
Flash Timing=3ffffffc
Configure Peripheral=True
Configure PLL0=True
Configure SDRAM=False
Configure PLL1=True
Configure DDR2=True
Configure LPSC=True
Configure Pinmux=False
Enable CRC=False
Specify Entrypoint=False
Enable Sequential Read=True
Use 4.5 Clock Divider=False
Use DDR2 Direct Clock=False
Use mDDR=True
ROM ID=3
Device Type=0
Input Clock Speed=24
Clock Type=0
PLL0 Pre Divider=1
PLL0 Multiplier=25
PLL0 Post Divider=2
PLL0 Div1=1
PLL0 Div3=5
PLL0 Div7=12
PLL1 Multiplier=22
PLL1 Post Divider=2
PLL1 Div1=1
PLL1 Div2=2
PLL1 Div3=3
Entrypoint=0
SDRAM SDBCR=0
SDRAM SDTMR=0
SDRAM SDRSRPDEXIT=0
SDRAM SDRCR=0
DDR2 PHY=c4
DDR2 SDCR=2034622
DDR2 SDCR2=0
DDR2 SDTIMR=189129c8
DDR2 SDTIMR2=380fc700
DDR2 SDRCR=c0000405
LPSC0 Enable=0+1+2+3+4+5+9+10+11+12+13+15+
LPSC0 Disable=
LPSC0 SyncRst=
LPSC1 Enable=0+1+2+3+4+5+6+7+9+10+11+12+13+14+15+16+17+18+19+20+21+24+25+26+27+28+29+30+31+
LPSC1 Disable=
LPSC1 SyncRst=
Pinmux=

  • 0 in reply to Yoel Motola
    Guru 26430 points

    A measurement of 160ns SPI clock for 8 bits every 3000ns leaves 2840ns idle. That is quite apalling considering polled IO usually results in no observable break between bytes. Just what is the ROM Bootloader doing? I guess it could be polling but that is usually only done when writing to SPI flash. Not reading.

    I think the CPU clock frequency comes out to 300MHz but I don't know if the ROMBL applies that change before or after processing. Hopefully the processor is not running at 24MHz..

     I'm using SPI boot with only 156KB and it goes by fast enough that I never looked into the actual signals. Seems that TI is strongly suggesting that first bit of code that runs after the ROM Booloader be very small. You might have to go the route of writing your own bootloader.

  • 0 in reply to Norman Wong
    Expert 1470 points

    Hey Norman,

    Thanks for the help and the advice, but I have 0 experience with bootloaders so I guess I won't go down that road right now.

    Maybe Titus can shed some light on what happens in this Idle time and how to shorten it. Titus??

  • 0 in reply to Yoel Motola
    Guru 26430 points

    I checked the AIS instructions in my AIS bin file. The PLL and clock programming command is before any load commands. In theory, the CPU should be running at the new clock speed while loading.