• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 97 subscribers
  • Views 539 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.

GEL File Updates Not fully taking effect?

Thomas Price7137
Intellectual 625 points
Other Parts Discussed in Thread: CCSTUDIO, OMAP-L138

I am using a 6748 SOM and am building a CCS v 3.3 project wtih BIOS 5.41.03.17 and CodeGen 7.0.1. I am also using a the gel file C6748.gel. I have modified it in some cases to test power consumption. So I will either use the call Core_300MHz_mDDR_132MHz(); to run at full speed or the call Core_100MHz_mDDR_102MHz();  to run at a much lower speed. I do see a significant difference in total board power consumption. However, I am questioning if the DDR speed is being adjusted. I am measuring the speed on R10 and it is consistently around 132 MHz no matter what I do in the gel file. I also have another project that uses PWRM and I always see that speed at 132 MHZ.

Also, I realize now that I need to reload the gel file and then disconnect and connect. I've pasted the GEL file output below as well.

Am I measuring this on the correct location?

Is there a way to measure the clock speed of the DSP somewhere on the SOM to verify the gel is setting it correctly?

GEL File Contents.

OnTargetConnect( )
{
    Clear_Memory_Map();
    Setup_Memory_Map();
    PSC_All_On_Experimenter(); //original
    //Core_300MHz_mDDR_132MHz(); //original

 Core_100MHz_mDDR_102MHz(); //Power Test TP

....

 Memory Map Cleared.
 ---------------------------------------------
 Memory Map Setup Complete.
 ---------------------------------------------
 Enabling Experimenter PSCs...
 PSC Enable Complete.
 ---------------------------------------------
 PLL0 init done for Core:100MHz, EMIFA:25MHz
 mDDR initialization is in progress....
 PLL1 init done for DDR:102MHz
 mDDR init for 102 MHz is done
 ---------------------------------------------

 

  • 0
    TI__Mastermind 27585 points

    Try reading the PLL1 multiplier register to see if the value changes depending on which function you run (100mhz vs 300mhz). If not, there is probably an issue with your gel function.

    Jeff

  • 0 in reply to jc-ti
    Intellectual 625 points

    I did check this now and am not seeing any difference in the PLL settings when I load the gel file. The function I am using to set the Core and DDR memory is a standard function that comes with the gel file. It should be setting the PLL's but it doesn't look like this is taking effect.

    At 100 MHz Core 102 MHz DDR I am expecting:

     Core Frequency

    PLL0_POSTDIV = 0x000080005
    PLL0_PLLDIV3 = 0x000080003
    PLL0_PLLDIV7 = 0x000080001

    Peripheral Frequency

    PLL1_PLLM = 0x00000010

    I am however seeing the 300 MHz, 132 MHz Settings:

    Core Frequency

    PLL0_POSTDIV = 0x000080001
    PLL0_PLLDIV3 = 0x00008000B
    PLL0_PLLDIV7 = 0x000080005

    Peripheral Frequency

    PLL1_PLLM = 0x00000015

    I have tried this restarting CCS as well as reloading the gel and disconnecting and reconnecting. The print output looks okay. Any idea why the gel settings wouldn't take effect?

  • 0 in reply to Thomas Price7137
    TI__Mastermind 27585 points

    Try running the PLL configuration from the dropdown menu:

    GEL->Frequency Settings

    On my board, clicking on the 102 MHz ddr setting changes 0x01E1A110 to 0x10.

    Jeff

  • 0 in reply to jc-ti
    TI__Guru 62975 points

    If your PLL settings are not changing, please check the SYSCFG_CFGCHIP3_PLL1_MASTER_LOCK bit to make sure that the PLL1 controller is not locked.

  • 0 in reply to tlee
    Intellectual 625 points

    The dropdown option definitely works. Not only do I see the bit change in value but I also see on the scope that the clock frequency to the memory has changed.

    I guess something isn't quite right in the gel file then. I'm not sure how I would check the SYSCFG_CFGCHIP3_PLL1_MASTER_LOCK  bit because it won't show up in the watch window when I try to add it.

    I do know that the code tries to unlock a bit at the beginning:

    device_PLL1(unsigned int PLLM,unsigned int POSTDIV,unsigned int PLLDIV1, unsigned int PLLDIV2, unsigned int PLLDIV3 ) {

       unsigned int i=0;

       /* Clear PLL lock bit */
       CFGCHIP3 &= ~(0x00000020);

    ....

       /* SET PLL lock bit*/
       CFGCHIP3 |= (0x1 << 5) & 0x00000020;

    }

    The gel file is located here: C:\CCStudio_v3.3\cc\gel\C6748.gel by the way. In the meantime the dropdown option will actually be able to provide what I need at this point. Thank you for your help.

  • 0 in reply to Thomas Price7137
    Intellectual 625 points

    Murphy's Law of course...

    I've now tried this on multiple different SOMs and on some SOMs I don't see the settings take effect even with the dropdown selection. Any idea why the settings wouldn't take effect even through the dropdown? The memory doesn't update in this scenario and the scope doesn't show the correct frequency having taken effect.

  • 0 in reply to Thomas Price7137
    TI__Mastermind 27585 points

    So some SOMs work and some don't? The ones that do work consistently though, correct? Can you provide the serial numbers of the working and non working ones so we can see if they are the same revision?

    Also try using the attached GEL file from the OMAP-L138 and see if that works.

    Jeff

  • 0 in reply to jc-ti
    Intellectual 625 points

    I'm actually still trying to isolate if it is the SOM or if the system just locks itself out of memory at times. I think I saw one SOM that wasn't updating and then when I popped it off and tried it again some time later, it did allow the update. I am keeping aware of the Beta SOMs we have vs. the A Rev SOMs.

  • 0 in reply to Thomas Price7137
    TI__Mastermind 27585 points

    Any updates on this issue or should we consider it closed?
    Jeff

  • 0 in reply to jc-ti
    Intellectual 625 points

    Yes, I was able to resolve this issue by adding the line "DEVICE_kickUnlock();" before any of the Core....(); lines.

    I can't explain why some SOMs seem to lock themselves out into a protective mode while others don't, but adding this line into my GEL setup was enabling me to get the SOMs to actually change the frequencies more consistently. I was able to verify this with a scope measurement on R10 (I believe) on the SOM which reflects the clock speed to the DDR memory.