What features dont work in low frequency mode?

Status
Not open for further replies.
S

srusha

Active member
Hi all
I am using Teensy 2++, when using 4Mhz frequency my program runs perfectly. but when switching to 2 or 1 Mhz sometimes it locks up after a while (could be between 1 minute to 1 day).

Now my intention here is NOT that you debug my code (which is quite long) but to find a document or anything else that can help me understand what issues can rise from using a low frequency.

I figured that windows doesn't recognize the com port when using less than 4Mhz. what else can go wrong when under 4Mhz?

(Right now my code uses interrupts, hardware serial, EEPROM and time functions.

Thanks for any tips

Izzy
 
By lock up you mean it stops functioning or you just cannot talk to the device?

Serial is a huge potential loss especially over USB.
 
srusha said:
I figured that windows doesn't recognize the com port when using less than 4Mhz. what else can go wrong when under 4Mhz?
Click to expand...

Generally, everything simply runs slower.

On the AVR chips (Teensy 2.0 and Teensy++ 2.0) you also tend to lose timing resolution, because hardware Timer0 has limited resolution and the interrupt rate scales down with clock speed (otherwise, it would burn far too much of the limited CPU time).

At only 2 MHz, the millis() count will tend to increment by 8 or 9 ms. Normally this isn't an issue for well designed code. But not-so-good code can work reliably when millis() increments 1 ms at a time, but fail when it jumps 8 ms at a time. For example, if you compute the time to do something in the future, and then read millis() and compare to see if it's equal to that time, you'll always succeed when millis() increments by 1. But when it jumps 8 ms at a time, it could easily jump past your target.

The same can be true for interrupts. Data sharing between and interrupt and the main program needs to be done carefully, usually by disabling the interrupt while accessing the data, and of course using "volatile" for the variables. But that alone is not always enough. Sometimes access to status or updates requires accessing multiple variables, or making a copy to use after interrupts are back on, and also updating status flags or other state info, so the interrupt knows you got the data. In some cases, the reading and/or writing and the updating of status or state variables needs to be done as one longer operation, with interrupts disabled for the whole thing. If interrupts are turned back on too soon, and then turned off again for another parts, it's possible the hardware interrupt could occur during that brief window of time where data has changed but related status/state variables haven't. When you scale down to slower CPU speeds, those tiny windows of opportunity for another interrupt at just the wrong moment become much greater.

It's also possible to simply stave for CPU time if you're processing a lot of interrupts per second, preventing the main program from ever running.

I have no idea if any of this applies to your program. You didn't post any code to reproduce them problem. But you did ask what might do it, and these are some of the tough timing related issues that can be masked by a few CPU speed but become troublesome, difficult-to-reproduce issues when the CPU speed changes.
 
Thanks Paul, I was looking for that kind of information. wondering if some peripherals just stopped working as well..

Demolish - I mean that the code stops running, (I have a led which blinks when the code runs and it get stuck to high)
 
srusha said:
I mean that the code stops running, (I have a led which blinks when the code runs and it get stuck to high)
Click to expand...

Perhaps you could trim this to a small demonstration program without any proprietary stuff, so you could post it here? (see the "forum rule")

The peripherals all still work down to 1 MHz, but slower and with less timing accuracy.
 
PaulStoffregen said:
Perhaps you could trim this to a small demonstration program without any proprietary stuff, so you could post it here? (see the "forum rule")

The peripherals all still work down to 1 MHz, but slower and with less timing accuracy.
Click to expand...
@srusha: Even if you hesitate to share your code, I found it always fruitful to generate a single page equivalent arduino-type code that is as simple as possible, but shows the same symptoms. Most of the time, by doing this I found the bug/conceptual error myself.
 
Last edited:
You guys are definitely right.

I will try to make a short program that (hopefully) reproduce the error.

Thanks
 
If you are slowing things down for power consumption you can do what a lot of low energy applications do:
  • Turn off all peripherals and assign wakup interrupts to specific peripherals.
  • Go into a low powered sleep mode.
  • When specific events occur via wakeup interrupts process the events.
  • Go back into sleep mode after tasks are completed.
 
There are hardware registers to control which things are powered.

On Teensy++ 2.0, the registers are PRR0 and PRR1, on pages 54-55 of the datasheet. By default, everything is on after reset, but you can turn things off to save power. If you try to access a power-down peripheral, random wrong results occur.

On Teensy 3.1, the registers are SIM_SCGC2 to SIM_SCGC7, documented on pages 250-257 of the reference manual. By default, almost everything is turned off after reset. The Teensyduino startup code turns on many of them. If you try to access a power-down peripheral, the result is a memory fault, causing the fault handler in mk20dx128.c to run.
 
Status
Not open for further replies.
Back
Top