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.

WinCE crash during initialization of power management chip by OAL

Other Parts Discussed in Thread: TPS65930, OMAP3530, TPS65950

Hello,

I am using BSP 6.14.00 for WinCE and OMAP3530 for my custom board.  During boot from SD card, the code crashes during initialization of power management chip (TPS65930).   I am able to narrow down to the following three lines of code located in the function InitT2PowerSequence().  The crash is gone when I comment them out.

 

 

 

OALTritonWrite(hTwl, TWL_P2_SW_EVENTS, 0x08); // P2 LVL_WAKEUP should be on LEVEL
   
OALTritonWrite(hTwl, TWL_P3_SW_EVENTS, 0x08); // P3 LVL_WAKEUP should be on LEVEL   

OALTritonWrite(hTwl, TWL_P1_SW_EVENTS, 0x18); // P1 LVL_WAKEUP should be on LEVEL

Using the same SD card on the EVM3530, the crash does not happen.  The EVM has TPS65950 instead of TPS65930 but according to my hardware guy, the chips are compatible.

There is a warning in the function OALPowerInit() (source file oem_pm.c) that calls InitT2PowerSequence() as below:

 

 

 

// If a UART is used during the basic intialization, the system will lock up.

 

 

 

 

// The problem appears to be cause by enabling domain power management as soon

 

 

// as the first device in the domain is initialized, instead of initializing all

 

 

// devices in domain before enabling domain autoidle. Since the system is single

 

 

// threaded when this function is called, the UART use during init is the only problem.

I tried both using and not using UART, the crash still occurs in both cases.

I would appreciate anyone's insights on this issue.

Thanks,

Luan

  • The following is from an email thread in reponse to Luan's question, from Tiemen Spits of TI, with a subsequent response from Luan, included here so that we don't go over the same ground:

    7/22/10

    Below are my answers to Tiemen's questions:  

    1.  The crash happens at the end of the power management initialization sequence; there are many writes to the I2C before that.
    2.  It happens during hardware initializations by the OAL.  I am not sure if the MMU has been enabled by this time.
    3.  Cache has been enabled by this time.
    4. There are no message on the serial debug port to indicate the kind of problem.  The function InitT2PowerSequence() is called by OEMInit() which is called by NKStart().  So it happens very early on.

    Please let me know if you have any suggestions for me to debug this problem.

    Thanks,
    Luan 
    --------------------------------------------------- 

    7/22/10
    Could be several things, first things to check are:
     
    1.        Is this the first access to the I2C controller for the TPS65950?
    2.        Are all the addresses called by the thread for this call mapped onto the memory via the MMU
    3.        Do they have I2 cache turned on
    4.        What type of crash occurs (i.e. kernel log up to the crash would be useful – kernel panic??)
     
    Cheers
    Tiemen T. Spits

  • As I said above, our custom board has a TPS65930.  We have BOOT1 and BOOT 0 configured as 01 for MASTER MC027 (as specified in the Data Book).  However, the OMAP 3530 EVAL board have the TPS65950 configured as 11 for Slave mode.

    Does it matter at all to the crash problem that I describe above?

    I appreciate your help.

    Luan

  • The EVM has the TPS in master mode (BOOT1 = 0, BOOT0 =1) 

    The lines you are commenting out affect how SLEEP and WARMRST affect the system.  My guess is there is some difference in how these signals are used between the 2 platforms.    Please check these signals.

    regards,

    James

     

  • Hi James,

    My problem has not been solved, so I still need help.

    On the EVM2 schematic (page 4, pins 82 and 84 of CONNECTOR A), both T2_BOOT1 and T2_BOOT0 of the TPS are pulled up through 4.7K resistors.  This makes the TPS a Slave.  On our board, the TPS has  0 for BOOT1 and 1 for BOOT0, making it a Master.

    My hardware guy says it does not matter during setting up the SLEEP and WARMRST through I2C1.  His response is below

    - Boot 1 and 0 has nothing to do with I2C master/slave

    -

     

     

    Boot 1 and 0 are dedicated (no alternate function after boot-up)

    Please let me know if you understand it differently.

    Thanks,

    Luan

  • Luan,

    Did you find out what the problem was and can you share how you got past this? Thanks.

    Jatin

     

  • Hi Jatin,

    Yes, it was our hardware design mistake; NSLEEP1 was pulled to GRD through a 0-Ohm resistor.  Therefore, when TWL_P1_SW_EVENTS register on the TPS65930 is configured for level wakeup, the software hung.

    Regards,

    Luan

  • Thanks for clarifying.