Forum Rule: Always post complete source code & details to reproduce any issue!
Page 2 of 2 FirstFirst 1 2
Results 26 to 32 of 32

Thread: Dynamic Clock Speed of Teensy 4.0

  1. #26
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,491
    Quote Originally Posted by Frank B View Post
    Yes, it prints a message, and switches off after that
    Thought I saw that noted ... so writing to RAM2 first would allow it to show on warm restart - but going to power down OFF losing RAM2? Maybe 'abuse' those RTC RAM bytes in case they are preserved?

  2. #27
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    840
    I could check with the scope, but does anyone know how long set_arm_clock() takes to execute? I see that it includes wait loops. Also that it's changing voltage - which might have some side effects.

    Right now, running with switching between 240Mhz and 600Mhz - this works OK and reduces temp by about 4C.

  3. #28
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,491
    Quote Originally Posted by jonr View Post
    I could check with the scope, but does anyone know how long set_arm_clock() takes to execute? I see that it includes wait loops. Also that it's changing voltage - which might have some side effects.

    Right now, running with switching between 240Mhz and 600Mhz - this works OK and reduces temp by about 4C.
    It takes some measurable time to make the change in clock speed. Checked it once some time back - but forget the numbers. It does have embedded while( wait for CPU makes change ); that are not finite and depend perhaps on the nature of the change to voltage or clocks as the CPU keeps things running across the changes.

    Adding a pin toggle or timing monitor to FranksB's posted code would show on scope or SerMon. Could use CYCCNT - but that changes across the change - not sure about time there either as micros() uses same CYCCNT against F_CPU_ACTUAL - so scope pin time would be best.

  4. #29
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    840
    Looks like it doesn't disable interrupts while waiting - seems like a potential source of problems.

  5. #30
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,366
    If I remember our testing correctly with temp and tempMon() it would hang before PANIC temp was reached, at least when we tested with the display attached. If was if some other part of the chip would fail before Panic temp. Forgot where we did that testing.

  6. #31
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    840
    Disabling interrupts around the call made it much worse. My working assumption - changing speeds simply takes too long to be useful in my use case.

  7. #32
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    7,988
    Quote Originally Posted by jonr View Post
    Disabling interrupts around the call made it much worse. My working assumption - changing speeds simply takes too long to be useful in my use case.
    Quite possible.

    I saw now that the ADC uses a timer that is connected to the Core-Clock:
    Code:
    const int comp1 = ((float)F_BUS_ACTUAL) / (AUDIO_SAMPLE_RATE_EXACT * 4.0f) / 2.0f + 0.5f;
    So, this will result in problems when changing the clock.

    It's possible that SPDIF3 uses IGP which is connected o the Core-clock too. Did not look at the sourcecode, now.
    Can you just try another SPDIF? The emulation uses I2S (which in turn uses the Audio-PLL)

    Good Night,
    Frank

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •