STM32L152 - Issue on wake-up from Standby (w/E-paper display) - Page 1
Forum section: electronics / general

author: norand
author_rank: Contributor
timestamp: March 08, 2020, 12:46:20 am
content: Hi All,I am working on my final year project, which is a RF energy harvesting project and am having an issue when waking my uC from standby so was hoping for a few pointers on places to look - but doesn't seem anything obvious (to me).Brief Overview: Essentially with this uC (I am using the STM32L-Discovery, STM32L152RB chip), putting the uC into standby mode will give lowest power consumption, but will also lose RAM and register contents etc. and wakes-up in a reset condition, but as we don't know when there will be enough power available this is okay.I wrote some code to test this worked properly just using some LED loops, and then a temperature sensor with LUT, and the onboard push button configured for wake-up and this all worked fine. I then wanted to integrate an E-paper display to my project (Waveshare 2.13" V2), upon wake-up of the uC I wanted the display to execute a partial refresh of the current display, as this takes less time than a full refresh, and hence will save power in the longrun. The code I wrote pretty much uses the libraries provided by Waveshare, and I have added some known data as a proof of concept that the wake-up routine is working and displays as expected.The issue I am facing, is that the partial refresh works as expectedONLY if the micro controller has been to sleep (standby mode) for less than ~10s. Any longer than this period and the image displayed appears corrupted. Stepping through the Keil Debugger, the data I am expecting to be there is correct, and this is almost verified by the fact the system operates correctly if only asleep for a short period. Also having a brief look on my old tek scope, nothing unexpected happens on the SPI bus, but I haven't decoded all the data (as I have a TDS210 and it would be very tedious, so would rather use the nice scopes on campus to do that job!).Things I have tried:Based of the fact the E-paper works of a charge pump, I assumed there may be wake-up delay for this, so I added a 13 second delay (for proof of concept) after the display initialisation which has had no effect, so therefore am ruling out the charge pump theoryI tried using the provided demo code, putting the display (only the display) to sleep for >10s, and then doing a partial refresh, and this worked again as expectedI also tried changing the partial refresh to a full refresh - and this also seems to work fine.The other thing I noticed, is on Wavehshares github, there is a new version of library code for this display, which has been updated in the last 2 months with the tag " 2.13 fix". So I looked through the changes (very minimal) and implemented them in the one I already had. This made almost no-difference.I am really struggling to see why the partial refresh won't work if it has been the uC sleep for a long period of time compared to a short? In my eyes, I have verified the code works (to an extent), and I have also verified the display is capable of the tasks I want it do. I know it's something to do with the when my uC wakes-up but can't put a finger on it. Any help would be really appreciated - I'm also still getting familiar with the firmware side of things so this is my best attempt! I have added some links that may be useful, but I'm hoping there is something obvious I am missing! Thanks in advance:Demo Code:https://www.waveshare.com/wiki/File:2.13inch_e-paper_code(V2).7zGithub for demo code:https://github.com/waveshare/e-PaperLink to my code (sorry all my Uni work is OneDrive not GitHub!):https://lunet-my.sharepoint.com/:f:/g/personal/elan4_lunet_lboro_ac_uk/EtQ_IwdpIa5CnMhqdx7Nd4MBnqaBt9oZAc5QVaMn7dlfFQ?e=Ko5t32

author: andersm
author_rank: Super Contributor
timestamp: March 08, 2020, 08:25:54 am
content: Is the behaviour the same if you press the reset button on the board?

author: norand
author_rank: Contributor
timestamp: March 08, 2020, 01:34:11 pm
content: Quote from: andersm on March 08, 2020, 08:25:54 amNo - as the main loop checks the wake-up flag, so on pressing the reset a full refresh is executed and hence behaves. It's only when the uController has been to sleep for more than ~10s the error occurs, which is why it is so odd.

author: ogden
author_rank: Super Contributor
timestamp: March 08, 2020, 02:00:32 pm
content: You would want to take scope and compare everything about e-paper power rails during full refresh after > 10sec sleep, partial refresh after > 10sec and < 10sec. You may find answer there. Looks like it is about capacitors somewhere close to e-paper, but from where I am it is hard to see where exactly. Also check init routines, experiment putting delays between main init steps. Init could be buggy - that do not account for some "middle" state of e-paper; between fully operational and fully powered-down.

author: Alti
author_rank: Frequent Contributor
timestamp: March 08, 2020, 02:18:08 pm
content: Debugging waking from standby, and low power modes in general is a tricky thing. I opt for an uninitialized auto variable, but that is just my guess.I'd start from:1. Checking Errata sheet.2. Swapping STM32L152RB to something similar (STM32L152RC)3. Dump SRAM memory map and do a diff.

author: andersm
author_rank: Super Contributor
timestamp: March 08, 2020, 03:15:03 pm
content: Quote from: norand on March 08, 2020, 01:34:11 pmI meant specifically if you held the reset button for over 10 seconds. I trust you use the library code specific to your display revision?

author: norand
author_rank: Contributor
timestamp: March 08, 2020, 04:44:09 pm
content: Quote from: andersm on March 08, 2020, 03:15:03 pmYes, using v2 code for v2 display, and holding the reset button seems to make no difference.Quote from: ogden on March 08, 2020, 02:00:32 pmI know I need to do this but the 24 pin flexi-connector is a pain! Will wait til I'm back on campus to do this with a proper 4 channel scope.Quote from: ogden on March 08, 2020, 02:00:32 pmI have tried this in various points in the part init routine, but doesn't seem to make any difference. I don't see why this seems so repeatable time-frame wise? Like I said previously, even if I add a big 13s delay after the Part Init, it still doesn't behave. I'm quite confused with this one.

author: ogden
author_rank: Super Contributor
timestamp: March 08, 2020, 04:55:32 pm
content: Quote from: norand on March 08, 2020, 04:44:09 pmSolution here: solder helper wire tails to connectorpinsPCB pads so you can use probe clips and free your hands.

author: norand
author_rank: Contributor
timestamp: March 08, 2020, 05:15:40 pm
content: Quote from: ogden on March 08, 2020, 04:55:32 pm[ Specified attachment is not available ]I mean it's still not ideal but I can give it a go!