Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 4 of 4

Thread: 4MHz VLPR (Very Low Power Mode) should be possible on Teensy 3.6, not just 2MHz

  1. #1
    Junior Member
    Join Date
    Jan 2019
    Posts
    10

    4MHz VLPR (Very Low Power Mode) should be possible on Teensy 3.6, not just 2MHz

    (Skip intro to next paragraph if you want) I am a veteran Windows programmer who is just getting into microcontroller programming. As my first post here, I want to congratulate Paul S. on your excellent product, your unabated development, and your honorable commitment to customer support. As the developer of a Windows software product with its own community, I am sympathetic to everything Teensy. I know what it's like to make a quality product that is a not the cheapest solution, but is the average consumer's best option. For me, when I saw that the Teensy Board could be compiled easily at low frequency, had a wealth of tested libraries, and especially when I saw 1) TeensyThreads and that 2) Paul ported FreqMeasure to the FreqMeasureMulti version - it became clear that Teensy was the best choice for my project. I am terribly excited about these boards and plan to NEVER go back to Adafruit!

    If it weren't for TeensyThreads and FreqMeasureMulti, I wouldn't be here. Never doubt that the incredible software development behind Teensy drives sales. I was indescribably excited when I found this hardware and software combo would solve my real-time pulse SD logger latency problems I'd been having on Adafruit boards, not using an RTOS.

    Back-on-topic question: I notice a non-linear, extreme savings in power when going from 4MHz to 2MHz. After some digging, I noticed it is because of "VLPR" which is activated in the Teensy code at 2MHz.

    According to spec here: http://cache.freescale.com/files/32b...ote/AN4503.pdf

    ...You should be able to activate this mode in 4MHz. But alas: it appears Paul's low-level bootloader code is already writing the "SMC_PMPROT" bit which is write-once-only. This would explain why my attempts to mess with the low-level registers on Teensy 3.6 @ 4MHz to activate VLPR have failed.

    Plugged into USB 5V I get 0.006A/6mA running at 4MHz, and 0.000A (my USB display can't even show the actual consumption, it's so low!) at 2MHz.

    I have profiled my application, and I need to be able to SD card write 1300 pulses/second (6 bytes of info each) without dropping any pulses. The TeensyThreads+SDFatSDIO combo has been amazing and I am extremely content with my purchase (I did fry/totally destroy my first Teensy 3.6 while wiring on breadboard, but good thing I bought 2, and I bought a third afterwards).

    However, the 2MHz/4MHz boundary seems to be the threshold between not good enough/good enough for my 1300 pulses * 6 bytes / second requirement, without dropping any pulses (mandatory).

    For this reason, I would love to have the power savings of VLPR @ 4MHz, and the only thing holding me back could be just a few lines of code in Paul's bootloader.

    1. Is it possible do to without a Teensy software update?
    2. If so, can someone post code for enabling VLPR @ 4MHz on Teensy 3.6?

    Many thanks in advance from an enthusiastic new customer.

  2. #2
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    2,321
    If I understand well, you are writing blocks of 6 bytes, 1300 times a second, to the SD card, which seems to be highly inefficient in my modest old eyes. Best SD performance is normally obtained when writing complete 512 byte blocks at once. Common practice is thus to “assemble” the data blocks in RAM and to write them out to SD once the buffer is full, while incoming data is filling a second buffer (ping-pong system).

  3. #3
    Junior Member
    Join Date
    Jan 2019
    Posts
    10
    I have done more testing/research and append the following possibly-useful information:

    According to Page 36 of the above-referenced PDF, at "8.1.1 Entering and exit conditions for each low power mode", Transition #3 in the table specifies that switching to VLPR requires only the following:
    "Set PMPROT[AVLP]=1, PMCTRL[RUNM]=10"

    I have subsequently 1) learned that SMC_PMPROT_AVLP is already getting set in SMC_PMPROT by the default Teensy code, and 2) tried to change PMCTRL[RUNM] to 10.

    I noticed where this is already being done for 2Mhz in line (1098) of mk20dx128.c :

    #if F_CPU <= 2000000
    // since we are not going into "stop mode" i removed it
    SMC_PMCTRL = SMC_PMCTRL_RUNM(2); // VLPR mode :-)
    #endif

    I then made two obvious tests, which both failed:
    1. I changed it to "F_CPU <= 4000000", recompiled with build all, and uploaded to Teensy 3.6. Result: There was no power savings beyond regular 4Mhz, and my program wouldn't run.
    2. I then add "SMC_PMCTRL = SMC_PMCTRL_RUNM(2);" as the first line in my setup sketch. Result: Now I get the power savings, (down to 2ma from 6ma), but my code does not run
    3. I remove that line from setup, and with the default mk20dx128.c, my code works perfectly at 4MHz invariably.

    Very strange. I also don't understand why the SMC_PMCTRL value is "2" in the Teensy code and "10" in the datasheet.

    I understand my test above might result in the reply, "what is your code/what is it doing". I admit I haven't fully minimized my code to a stripped-down failure example when setting the register on setup. Maybe someone can help before that would be necessary.

    Are there conflicts with the settings of other registers that could be causing this?
    Last edited by Paul_M; 01-02-2019 at 06:59 AM.

  4. #4
    Junior Member
    Join Date
    Jan 2019
    Posts
    10
    Quote Originally Posted by Theremingenieur View Post
    If I understand well, you are writing blocks of 6 bytes, 1300 times a second, to the SD card, which seems to be highly inefficient in my modest old eyes. Best SD performance is normally obtained when writing complete 512 byte blocks at once. Common practice is thus to “assemble” the data blocks in RAM and to write them out to SD once the buffer is full, while incoming data is filling a second buffer (ping-pong system).
    Don't worry, I am implementing exactly that with a ping-pong buffer that is in multiples of 512 and indeed much larger than 512. Writes happen much longer than every second except at full speed. That is a good piece of feedback in response to reference of a goal like mine, but the VLPR topic is separate.

Posting Permissions

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