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

Thread: ILI9341_t3(n) and snooze, power consumption in hibernate

  1. #1
    Senior Member
    Join Date
    May 2017
    Posts
    106

    ILI9341_t3(n) and snooze, power consumption in hibernate

    Hello,

    I have a 2,2" ILI9341 on a teensy 3.2 using ILI9341_t3 and snooze libraries (display connected standart wise, like on PJRC web site shown).

    When I go to hibernate (snooze) it still draws current of app. 35mA.
    Backlight was switched off before (via FET), also powerline of display was switched off before (via FET) and set display into sleep.

    When I disconnect the display from the circuit and set to hibernate, I get the expected current below 1 mA.

    I can't imagine whats the reason for the high current. Maybe some strange correlation between SPI and snooze?

    Any ideas?

  2. #2
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    8,465
    Maybe,

    You need a way to turn the display into sleep mode. I believe that is command 0x10

    And then later may need to have it exit sleep mode (0x11)

  3. #3
    Senior Member
    Join Date
    May 2017
    Posts
    106
    Quote Originally Posted by KurtE View Post
    Maybe,

    You need a way to turn the display into sleep mode. I believe that is command 0x10

    And then later may need to have it exit sleep mode (0x11)
    Thank you for your answer, but I did this by using function "sleep(true)" from ILI9341_t3n library before power off display and go hibernate.

  4. #4
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    8,465
    Sorry, hopefully someone who uses snooze library can help answer. Same code running with display (35ma) and without display (1ma)? Or different code?

    Maybe power associated with IO pins connected to SPI. (default connections like pins 9-13?)
    Wonder if you need to more or less turn off these pins while in sleep mode and then reinitialize after?

    I don't think either the main ili9341_t3 library or mine (ili9341_t3n) has any support functions for this (like and end method) and I have never tried it, but wonder if you need to put all of these pin into not used (mode 0?) And when you wake back up need to put them back into SPI mode (which I believe these are all mode 2.

    Something like when you go to sleep lines like: CORE_PIN9_CONFIG = 0;

    And when you wake up? If you actually turned power off to the display board, do you then have to run through begin method again to output all of the initialization of the board? If not, then you would need to reset the pins to their correct SPI mode.

    For most SPI pins it would be something like: CORE_PIN9_CONFIG = PORT_PCR_MUX(2);
    There are some pins on T3.2 that also set PORT_PCR_DSE, which from SPI tables I believe this is done for pins 11 and 13)
    That is it is something like: CORE_PIN13_CONFIG = PORT_PCR_DSE | PORT_PCR_MUX(2);

    Again not sure if that is the issue or not

  5. #5
    Senior Member
    Join Date
    May 2017
    Posts
    106
    Quote Originally Posted by KurtE View Post
    Sorry, hopefully someone who uses snooze library can help answer. Same code running with display (35ma) and without display (1ma)? Or different code?

    Maybe power associated with IO pins connected to SPI. (default connections like pins 9-13?)
    Wonder if you need to more or less turn off these pins while in sleep mode and then reinitialize after?

    I don't think either the main ili9341_t3 library or mine (ili9341_t3n) has any support functions for this (like and end method) and I have never tried it, but wonder if you need to put all of these pin into not used (mode 0?) And when you wake back up need to put them back into SPI mode (which I believe these are all mode 2.

    Something like when you go to sleep lines like: CORE_PIN9_CONFIG = 0;

    And when you wake up? If you actually turned power off to the display board, do you then have to run through begin method again to output all of the initialization of the board? If not, then you would need to reset the pins to their correct SPI mode.

    For most SPI pins it would be something like: CORE_PIN9_CONFIG = PORT_PCR_MUX(2);
    There are some pins on T3.2 that also set PORT_PCR_DSE, which from SPI tables I believe this is done for pins 11 and 13)
    That is it is something like: CORE_PIN13_CONFIG = PORT_PCR_DSE | PORT_PCR_MUX(2);

    Again not sure if that is the issue or not
    Thanks for your suggestions,

    - yes, same code with or without display
    - yes, default pins 9-13 for SPI
    - after wake up I use begin methode, it works; didn't try it without until now

    I will try your ideas to put SPI pins in not used mode. Assume your begin function put it back to service (SPI mode) or have I do myself?
    Honestly, i am not the software specialist. Wrote a big programm (about 2300 lines source code, I think a good software guy would do in a quater of this lines), using many functions of teensy libraries (I think they are for this ). But exept the issue with the power consumption in hibernate it works.

    Your help will be appreciated.

    Best regards

  6. #6
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    8,465
    Calling the Begin function should put all of the pins into their appropriate modes. Again I have never tried calling it a second time. Let me know if it works or not. If not may need/want to add support for it.

  7. #7
    Senior Member duff's Avatar
    Join Date
    Jan 2013
    Location
    Las Vegas
    Posts
    1,025
    The clock pin needs to be output low, You need to reconfigure the clock pin after waking though.

    I'll add a SPI driver in the upcoming update to Snooze that handles all the pins correctly. It won't put the SPI device to sleep mode, that will up to the user to do that.

  8. #8
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    8,465
    One thing I should mention, that might make your code cleaner than what I mentioned.

    I believe that with current Teensy stuff instead of doing: CORE_PIN9_CONFIG = 0;
    You can now do pinMode(9, INPUT_DISABLE);

  9. #9
    Senior Member
    Join Date
    Dec 2014
    Posts
    310
    Just to confirm as I have a similar setup using snooze and ILI9341 but hadn't actually verified the power consumption yet...
    Are we suggesting that leaving the SPI CLK pin high is preventing the teensy from hibernating? If so, why would that be?

  10. #10
    Senior Member duff's Avatar
    Join Date
    Jan 2013
    Location
    Las Vegas
    Posts
    1,025
    Quote Originally Posted by Cosford View Post
    Just to confirm as I have a similar setup using snooze and ILI9341 but hadn't actually verified the power consumption yet...
    Are we suggesting that leaving the SPI CLK pin high is preventing the teensy from hibernating? If so, why would that be?
    It will still work just configuring it as output low reduces current.

  11. #11
    Senior Member
    Join Date
    Dec 2014
    Posts
    310
    What is the current draw of the display when plugged in, with the Teensy not running?
    You say that the power to the display is turned off with a MOSFET; Can you verify this with a meter?
    A FET that is turned the wrong way will work as a diode, for example ...

  12. #12
    Senior Member
    Join Date
    May 2017
    Posts
    106
    Quote Originally Posted by KurtE View Post
    One thing I should mention, that might make your code cleaner than what I mentioned.

    I believe that with current Teensy stuff instead of doing: CORE_PIN9_CONFIG = 0;
    You can now do pinMode(9, INPUT_DISABLE);
    Thanks for you help.

    As you suggested I did the following before go hibernate:

    tft.sleep(true);
    for (uint8_t k = 9; k < 14; k++) {
    pinMode(k, INPUT_DISABLE);
    }

    And now the current in hibernate is as expected around 0.3 mA.

    I call your begin methode after every hibernate (is like switch off my device) and it works for me. SPI seems to be restored after begin(). Giving the hardware always a 50ms delay before doing anything after switch on power for display via MOSFET.

    May be a end methode might be also a usefull extension for the library.

    Best regards
    Last edited by larry_berlin; 07-23-2017 at 02:58 PM.

  13. #13
    Senior Member
    Join Date
    May 2017
    Posts
    106
    Quote Originally Posted by jwatte View Post
    What is the current draw of the display when plugged in, with the Teensy not running?
    You say that the power to the display is turned off with a MOSFET; Can you verify this with a meter?
    A FET that is turned the wrong way will work as a diode, for example ...
    Thanks for your hint, but SPI seems to be real problem.
    See above.

  14. #14
    Senior Member
    Join Date
    May 2017
    Posts
    106
    Quote Originally Posted by duff View Post
    The clock pin needs to be output low, You need to reconfigure the clock pin after waking though.

    I'll add a SPI driver in the upcoming update to Snooze that handles all the pins correctly. It won't put the SPI device to sleep mode, that will up to the user to do that.
    Adding a SPI driver to snooze is a very good idea, as this could prevent problems like mine. Can you tell when do you plan to do this, please?
    Anyway your snooze library is very helpfull. Thanks for you effort.

    May be you can take closer look on your SnoozeSleepPWM. I tried to use it during short sleep periodes (25ms) in loop() to maintain pwm for a display LED backlight, but with lower pwm values I had flickering (backlight). I always restored normal pwm on the pin after every sleep() by analogWrite().
    Maybe a fault in my code.

  15. #15
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    8,465
    Quote Originally Posted by larry_berlin View Post
    May be a end methode might be also a usefull extension for the library.
    I should also mention, that part of this can be done by using: SPI.end();
    This will do the equivalent of pinmode INPUT_DISABLE on the SCK, MOSI, and MISO pins.
    But does not do anything with your chip select pins (CS and DC).

    My problem of adding it to ili9341_t3n library (and likewise other libraries) is, not sure what it should do in many cases.

    That is if this is the only SPI device connected, than it might be easy.
    That is it could set the DC pin to disabled and call the appropriate SPI end method.

    Not sure generically, what should happen with CS? Should it just be disabled like the others? Should it be set into not-asserted state?

    But suppose you have multiple SPI devices. For example the display and touch screen. If you call a new tft.end() method and it call SPI.end and then you try to do something with the touch device, What should happen?

    If all of this was done as new code, one could potentially have usage counts for SPI. That is SPI.begin() would increment a usage count and SPI.end() would decrement the count and only when it goes to zero does it actually disable the SPI pins... But then again this would get back to what to do with CS pins....

  16. #16
    Senior Member
    Join Date
    May 2017
    Posts
    106
    Quote Originally Posted by KurtE View Post
    I should also mention, that part of this can be done by using: SPI.end();
    This will do the equivalent of pinmode INPUT_DISABLE on the SCK, MOSI, and MISO pins.
    But does not do anything with your chip select pins (CS and DC).

    My problem of adding it to ili9341_t3n library (and likewise other libraries) is, not sure what it should do in many cases.

    That is if this is the only SPI device connected, than it might be easy.
    That is it could set the DC pin to disabled and call the appropriate SPI end method.

    Not sure generically, what should happen with CS? Should it just be disabled like the others? Should it be set into not-asserted state?

    But suppose you have multiple SPI devices. For example the display and touch screen. If you call a new tft.end() method and it call SPI.end and then you try to do something with the touch device, What should happen?

    If all of this was done as new code, one could potentially have usage counts for SPI. That is SPI.begin() would increment a usage count and SPI.end() would decrement the count and only when it goes to zero does it actually disable the SPI pins... But then again this would get back to what to do with CS pins....
    I see the problem, but also have no clue how to solve this.
    As duff wrote a SPI driver for his snooze lib might be the right way (related to low power applications).

  17. #17
    Senior Member
    Join Date
    Dec 2014
    Posts
    310
    Quote Originally Posted by duff View Post
    It will still work just configuring it as output low reduces current.
    Sorry, I still appear to be missing something here.
    Why would disabling the CLK pin reduce current draw from 35mA to 0.3mA?

  18. #18
    Senior Member
    Join Date
    May 2017
    Posts
    106
    Quote Originally Posted by Cosford View Post
    Sorry, I still appear to be missing something here.
    Why would disabling the CLK pin reduce current draw from 35mA to 0.3mA?
    For clearification:
    First I just put pin 9 (DC) in not used mode ( by pinMode(9, INPUT_DISABLE); ), then the current droped from 35 mA to 25 mA in hibernate.
    Finaly I put all hardware SPI pins of teensy 3.2 into not used mode, then I got the expected current of 0.3 mA in hibernate.

    I don't know how the ILI9341 chip internally works, but apparently came the current from the hardware SPI pins of teensy to ground.
    May be another solution would be to switch off the ground of the display also off (via MOSFET) like the power line.

Posting Permissions

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