• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 30 subscribers
  • Views 677 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.

Problem in system control clock and current consuption in LM4F120H

brolin p john
Prodigy 170 points


I bought a stellaris launchpad evaluvation board(LM4F120H) and firstly i was checking the current consuption in different frequencies.I varried the frequencies using the function "sysctlclkset().When i plot the reading for 40,25,20,10,5MHz i got linear variation in current-frequency.But when i plotted for 50 MHz  it showes a current less than for 40MHz frequency.I varried the frequency by changing the PLL Dividing factor.

  • 0
    Guru 117855 points

    Note a very similar post - different author - on rebrand forum.

    Have you employed one of the timer pins - set up in PWM mode - as an eased method to measure System Clock? 

    Most all CMOS devices exhibit current demand increasing - with rising frequency.  May suggest that your System Clock adjustment is incorrect. 

    SysCtlClockSet(SYSCTL_SYSDIV_4 | SYSCTL_USE_PLL | SYSCTL_XTAL_YOURXTALFreq | SYSCTL_OSC_MAIN); // yields 50MHz across multiple, different Stellaris devices we've used since 2007...

    Be cautious about mismatch between your board's xtal - and parameter entry - above.  (loss of JTAG awaits...)

  • 0 in reply to cb1_mobile
    Prodigy 170 points

    Sir,i'm working with the programs given by ti.i just modify the PLL dividing factor.

    for 50MHz->

    SysCtlClockSet(SYSCTL_SYSDIV_4| SYSCTL_USE_OSC | SYSCTL_OSC_MAIN |
    SYSCTL_XTAL_16MHZ);

    for 40MHz->

    SysCtlClockSet(SYSCTL_SYSDIV_5 | SYSCTL_USE_OSC | SYSCTL_OSC_MAIN |
    SYSCTL_XTAL_16MHZ);

    for 25MHz->

    SysCtlClockSet(SYSCTL_SYSDIV_8 | SYSCTL_USE_OSC | SYSCTL_OSC_MAIN |
    SYSCTL_XTAL_16MHZ);

    for 20MHz->

    SysCtlClockSet(SYSCTL_SYSDIV_10 | SYSCTL_USE_OSC | SYSCTL_OSC_MAIN |
    SYSCTL_XTAL_16MHZ);

    This was the same method used in sample programs that was given in tivaware

  • 0 in reply to brolin p john
    Guru 117855 points

    That's what was understood - your 1st post - and your code for System Clock seems perfect.

    Have you repeated the test to confirm the apparent "drop" in current - when moving from 40MHz to 50?  (sometimes - in haste or excitement - staff or I will modify the code - but fail to compile & download - and run that "latest/greatest" - with no changed results.)

    Only thing else which may impact - I recall reading that beyond 40MHz - MCU inserts wait states. 

    Suspect that if your test code is highly active in toggling GPIO outputs - that would maximize current usage.  And - if SYSCTL_SYSDIV_3 is legal/allowed - your MCU - that should bring you up to ~ 66MHz - may be interesting to measure/report there too...

  • 0 in reply to cb1_mobile
    Prodigy 170 points

    Sorry ,i'm a bit late to reply.

    Also i thank you for the valuavable information.Yes after 40Mz wait states are included.Can u also help me how it makes much difference in current consuption.In data sheet ,it says only wait states will be included,but processor works in the clock frequency as assigned wether it is 50,-80MHz.

    Anyway your information was very helpful.

    i also share you the current-frequency chara.This might me helpful for u in any cases.

  • 0 in reply to brolin p john
    Guru 117855 points

    Suspect that's your spreadsheet export - believe you've done a nice job.  And - like you - I've few real answers.

    Sometimes - when things defy normal/customary - best to examine if, "anything else may be impacting." 

    What code is running while you conduct such tests?  (general description adequate)  What else may be intruding upon your current measurement?  (we don't have that board)  Might your code make extensive use of MCU SRAM?   Are your GPIO connected - or floating - are they configured as inputs or outputs.  As the GPIO normally default into inputs - and should they be allowed to "float" - might this be a cause?  (you are aware - MCU inputs should not float!)  (you may solve "floating" via configuring unused inputs with WPU or WPD via GPIOPadConfig() function)

    TI's Lela G. visited this subject - other forum - also reported linear current w/System Clock expectations...

  • 0 in reply to cb1_mobile
    Prodigy 170 points

    I'm doing the program for adc,here i use sram to store the adc output.In the program,i use different channels which is multiplexed with gpio pins.in my program fpu is also enabled.

  • 0 in reply to brolin p john
    Guru 117855 points

    Should you seek deeper insight - suggest that you remove all external (other than power) connections to your board - then enable just one peripheral at a time - and repeat your measurements.  Insure that GPIO's do not float - likely best to test w/GPIO all set to input - first w/WPD - later w/WPU.  (will reveal GPIO's termination impact)

    By measuring one peripheral at a time - you may better determine which (if any) most impact the "unexpected" current demand you note...

    As always - such testing on "single board" enables dreaded "single-board anomaly" - which normally reduces factory interest...  Testing - and repetition of such issue - across several boards/devices - raises the impact of that issue...

  • 0 in reply to cb1_mobile
    Prodigy 170 points

    ok.Thanks.i understand.I'm  happy.