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.

Problem with OMAPL137 Pre-defined Boot ROOM “5" function

Other Parts Discussed in Thread: OMAP-L137

This time I have to address the boot – topic of C6747 (DA808, OMAP L137).

 

We use the master SPI boot process and the AIS format. Let me explain how we (I) do it.

 

Creating the AIS image is done using the TI tool HexAIS_OMAP-L137 .

 

In order to speed up the boot time, on the very beginning of the load process we use so called “Pre-Defined ROM Functions” foreseen by TI (as described in the document SPRABB1C ).  

For many years we have been using the separate ROM functions for DSP Core-Pll setup and SPI configuration:

For many years we (out of 8 available Pre-defined ROM functions) have used two functions:

  • Function 0 (PLL Configuration) 
    setup via "OMAP-L137.ini" [PLLANDCLOCKCONFIG] section
  • Function 1 (Clock Configuration)
    setup via "OMAP-L137.ini" [PERIPHCLKCFG] section

 

For some specific reason this solution is not suitable. Why?

 

  1. In C6000 core clock is used for generation of the peripheral clock SYSCLK2:
    Fperipherals = SYSCLK2 = PLLOUT / DIV2   =  PLLOUT / 2 
  2. The clock rate for data format x can be calculated as follows:
        SPI-Clock = SYSCLK2 / (PRESCALEx + 1)   ...PRESCALEx determines the bit transfer rate of data format x if the SPI is the network master.

 

 

Well, if two configurations (mentioned above) are performed one after another (first core-Pll, then SPI) using separate commands, for a short time SPI (being configured afterwards) runs fast, too fast. Why?

Because it depends directly on the core-clock.

  1. Core clock of the DSP is set to some default value (SPI Master/25 MHz Quarz:  962 kHz).
  2. First ROM-function (“0”) is applied and peripheral clock (deriving from it) is of an undesired value (the command defining it comes yet, afterwards)
  3. Second ROM-function (“1”) gets fetched (using an irregular SPI inter-state) and executed; now SPI is set properly.

However, between steps 2 & 3 there’s an undesired ‘glitch’ of undefined state of SPI registers.

 

This topic is known to Texas Instruments very well.

 

For this reason, a special ROM command was implemented performing both setups (PLL and Clock Configuration) – at once! Using one ROM-function “5”  only.

In the manual (SPRABB1C) this method is even the preferred one:

Function 5 (PLL and Clock Configuration)
setup via "OMAP-L137.ini" [PLLANDCLOCKCONFIG]
This function combines the PLL configuration and clock configuration functions into a single function call. This function takes three arguments.
The first two arguments match the arguments for the PLL configuration function, and the third argument matches the argument for the clock configuration function.
It is preferable to call this function when the I2C, SPI, or UART modes are being used rather than calling the PLL configuration and clock configuration functions separately; since it ensures that the system PLL and the peripheral's clocks are changed together.

 

I immediately knew it was the solution to preventing the ‘glitch’.

Unfortunately, for some reason my application does not start if I use this method (function “5”).
The boot process gets finished, but DSP application cannot run.
I assume some problems with the DSP PLL.

 

Returning the boot method to initial approach (using separate functions 0 & 1) causes application to boot successfully again. However having an unwanted SPI ‘glitch’ in between.

 

So finally my question:

  1. What could be the reason Pre-defined Boot ROOM “5” couldn’t work?
  2. Where could I find some more details on function “5” internal behavior?

 

I’ve tried to add the delay (“PLL_LOCK_TIME_CNT”) after PLL-setup, but it didn’t help.

Additionally, I removed the PLL-setup in the application (since PLL is already configured in the process of booting), bit this neither helped.

 

Many thanks for your support!

Regards from Vienna,

Mladen

 

Appendix:

AIS File Containing
Command OpCodes


0x41504954, MAGIC WORD ('T','I','P','A')

0x58535963, Function Sequential Read Enable Command
(without sending READ-command for each byte)

0x5853590D, Function Execute Command (DSP-Inits prior to load process)
0x00030005, ARG CNT (3) & FXN NUM (5 = PLL and Clock Configuration)
0x10000205, PLLCFG0: PLLM=0x10, POSTDIV=0 (/(0+1)), PLLDIV3 (for EMIFA), PLLDIV5 (for EMIFB)
0x00070800, PLLCFG1
0x00000014, SYSCLK2 of 200 MHz / PRESCALE of 0x14 ie. 20 => 10 MHz SPI-Clock

0x58535903, ENABLE_CRC_COMMAND

0x58535901, SECTION_LOAD_COMMAND
0x11800000, Section start-address (section: .text)
0x00006900, Section-Length [Bytes]
. . . . .

 

 

  • Hi Carlos,

    Thanks for your detailed note.

    We will look into it and get back.
  • Dear Carlos Ventura,
    Can you please provide both the application AIS binaries and ini files used for failed and worked cases ?

    1) ini file and AIS binary used while performing ROM BOOT Function 0 and Function 1. ( working case: Separate PLL and clock configuration )
    2) ini file and AIS binary used while performing ROM BOOTFunction 5 (failed case: Combined PLL and clock configuration)

    Also please run the debug gel file once it hung up and not booting.

    Share the debug gel file output too.
    processors.wiki.ti.com/.../OMAP-L1x_Debug_Gel_Files
  • Carlos,

    • Are you using the latest version of the OMAPL137 AISGen tools v0.8.2.0 ?

    • What is the device speed grade. With current customer setting , the device clock is being set to 425 Mhz not 400 Mhz.  Can you also check if the SYSCLK3 is in spec with DIV3 set to 3. I think they need to enable to 4.5 divider to get within 100Mhz as the spec for SYSCLK3 specifies.

    Check the screenshot here for 400Mhz settings. Can they try these settings and let us know if there is any improvement.

    • Can they provide the debug GEL file output requested by Titus. The GEL will capture errors Bootloader reported if there are any issues recognized by the ROM.

    • Have you measured the resulting SPI clock or SYSCLK on the scope to see if the device was configured as specified in the AIS settings.

    Regards,

    Rahul

  • Rahul,

    could you please provide me with the latest version of the OMAPL137 AISGen tools v0.8.2.0 you mentioned in your post from above?
    Is there a command-line version, too?

    Here details the version we use:

    v 2.40 (OMAP-L137_FlashAndBootUtils_2.40 from "OMAP-L137_FlashAndBootUtils_2_40.tar")

    Regards,

    Mladen

  • You can get the latest AISGen tool version from below link.
    wwws.ti.com/.../sprab04.zip
  • Thanks for the link.

    Please allow following question.

    Question 1: Is there a posibility of adding to an .AIS file content not doing anything?

    Background of my question:
    I'd need to append a content into .AIS (its initial part containing ROM functions) that has a length of 8 bytes.

    I thought of the following command:

    The tool .ini file includes the following section:

    ; No Params required - simply include this section for the fast boot function to be called

    [FASTBOOT]

    Question 2 - what is this section used for?

    Is it applicable for OMAP L137 DSP?

    Regards,

    Mladen

  • Mladen,

    No, FASTBOOT command is a legacy command that is not supported for OMAPL137 DSP. TO add bytes, you could use Boot Table Command that is described here:
    www.ti.com/.../sprabb1c.pdf

    You can insert this section using :
    [AIS_Set]
    TYPE=Type field for AIS SET/BOOT_TABLE command
    ADDRESS=Address field for AIS SET/BOOT_TABLE command
    DATA=Data field for AIS SET/BOOT_TABLE command
    SLEEP=Sleep field for AIS SET/BOOT_TABLE command


    OR

    you can use custom input by using the syntax shown below. this has been tested on C6748 but i think it is supported on C6747 as well.


    ; Get the NAND ECC patch for the ARM
    [INPUTFILE]
    FILENAME=padding.out

    Regards,
    Rahul
  • The other way to introduce 8 bytes would be to use PSC configuration function :

    ; This section should be used to setup the power state of modules
    ; of the two PSCs.  This section can be included multiple times to
    ; allow the configuration of any or all of the device modules.
    ;           |------24|------16|-------8|-------0|
    ; LPSCCFG:  | PSCNUM | MODULE |   PD   | STATE  |
    ;[PSCCONFIG]
    ;LPSCCFG=

  • Mladen,

    Is this issue resolved yet? If not, can you provide the log of the Debug GEL file when the boot fails with ROM function 5 for us to analyze.

    One other issue is for 400Mhz configuration, you need to set the core voltage to 1.3V instead of nominal 1.2 V. Can you confirm the core voltage is 1.3V.

    Regards,
    Rahul
  • Hello once again.

    Please let me report that the boot- issue I've faced that brought me to generate this post has been resolved.
    Many thanks for your support.

    Let me explain the background of the issue.

    In a system architecture our OMAP L137 is embedded, it does boot in master SPI mode, but boots not from a physical (serial) flash, but only acts as such (SPI boot-master).

    Another general-purpose CPU performs the task, of providing it with the content of .AIS emulating serial flash.

    Due to the change of .AIS starting file configuring the DSP ROM Bootloader (using Pre-Defined ROM Function 5 only, instead of two, 0 and 1), the whole .AIS file got shorter causing the flash-emulation to perform erroneously.

    So, it wasn't a TI ROM Bootloader issue.


    Still, your support helped me realize that DSP PLLM (PLL Multiplier Control Register) saves multiplier in the following format:
    PLL Multiplier Select. Multiplier Value = PLLM + 1


    After many years of using Pre-Defined ROM Functions 0 and 1, I'd propose everyone to use the ROM Function 5 instead.
    In L137 (and many other similar C6000) SPI is clocked by SYSCLK2 which in turn is gained from DSP Core Clock as follows:

    Core clock PLLOUT setup:
      PLLOUT =  ( XTAL * PLLM )  / POSTD 

    Peripheral clock SYSCLK2 used (among others) for SPI is gained out of DSP core clock as follows:
      SYSCLK2 = PLLOUT / (2*PLLDIV1)

    So if DSP performs two separate SPI accesses in order to perform two different ROM functions, after performing the first one, core clock will get changed, and SPI (deriving from it) will 'gain' a setting which is undefined, and gets finally defined after the next (ROM function 1) gets fetched completely and SPI-prescaler finally configured.

    For a short time of fetching the second, ROM-function 1 (residing in external flash) using SPI-itself, SPI clock is undefined, which may lead to faulty boot process.

    Regards,

    Mladen

  • This case can be considered resolved.

    Regards,

    Mladen