I'd like to know which is the best way to measure current consumption on this demo board.
I need to verify standby current consumption.
Is there something similar?
Thank you for reaching out to the Renesas Engineering Community!
There is also a measurement available for the current drawn by the evaluation MCU for your RL78/G22 Fast Prototyping…
There is also a measurement available for the current drawn by the evaluation MCU for your RL78/G22 Fast Prototyping Board. You can find the documentation at this link: rl78g22-fast-prototyping-board-users-manual. However, please note that the J11 header is not mounted on the board, and you need to cut the VDD pattern.I would also recommend placing a Shunts Short Circuit Cap/Header Pin Jumper Cap in the J11 slot in case you no longer need to measure the current.
I hope this helps!
Regards,JefIf this response, or one provided by another user, answers your question, please verify the answer. Thank you!Renesas Engineering Community Moderatorshttps://community.renesas.com/https://academy.renesas.com/en-support.renesas.com/.../
Is there an example for using Touch peripheral in a low power environment (similar to the example for RTK0EG0042S01001BJ) ?
Thank you for updating, I'm working on your code, but I don't have hardware in hand.
I'll share you the possible solutions about that and explain those, I hope it will help. Thanks for your patience.
Assuming the problem is RM_TOUCH_SmsSet(g_qe_touch_instance_config02.p_ctrl),
I investigated on the register values.
These are the following while CPU is stuck in stop mode:
PER1 register: CTSUEN = 1, TML32EN = 1, SMSEN = 1
PPR1 register: CTSURES = 0, TML32RES = 0, SMSRES = 0,
SMSC register equals 0x85: SMSSTART = 1, SMSSTOP = 0, SMSTRGWAIT = 0, LONGWAIT = 0,
SMSTRGSEL3 = 0
SMSTRGSEL2 = 1
SMSTRGSEL1 = 0
SMSTRGSEL0 = 1
which means that the snooze mode sequencee activation trigger is the ELC output signal.
ELC, in my case, links a 32bit timer to the CTSU (ELSELR10 = 0x06U instruction).
Maybe the SMS is not triggered.....
SMSSTAT bit of SMS register equals 0, so the SMS is not operating.
As you might already know here’s a document for this:
at the page 8, the procedure and concepts of using Snooze mode sequencer for touch unit is being demonstrated.
As document says we must configure 2 free GPIOs (Which are physically connected together) for trigger the ELC unit by CTSU. One GPIO which applies interrupt pulse for triggering ELC unit (after touch measurement is done), then ELC triggers SMS for judgement touch (the procedure and settings for simulating CPU in SMS is done by configurator)
That’s why we have to set external interrupt GPIO and specify external trigger PORT in configurator.
So, in configurator, output port number for external trigger and Bit number for external trigger must be specified as a normal output GPIO and must be connected physically in board to another input GPIO pin (configure this GPIO as OUTPUT and set it to 0 initially).
At the other hand, in configurator, the parameter “interrupt port number for external trigger” we have to specify the GPIO’s Port which we’ve connected external trigger pin to it and configure the INTPn interrupt like a simple external interrupt.
And as you already know, Snooze sequencer is acting like CPU, but it cannot handle massive instructions like that. (The instructions and memory managements are structed by configurator)
Also, The document implies, we cannot use this feature (auto judgment touch) for this number of capacitive touch in snooze mode, “This feature does not perform with the self-capacitance to 9 elements or more and the mutual capacitance to 8 elements or more.”
In this way, probably we won’t have any conflict with instructions, and after sensing a touch CTSU will be judged by SMS, and after sensing a touch SMS will generate an Interrupt (INTSMSE interrupt) then CPU will start normal operation and goes for getting touch data.
Also there's a specific document for implementing capacitive touch in snooze mode and low power consideration of it which you might find helpful.
Don't hesitate to ask further questions and tell me if it helped.
With best regards
Thanks a lot, I will try to apply your suggestion.
This means that the example that I took for RTK0EG0042S01001BJ board
is working in the RTK0EG0042S01001BJ board because P22 and P16 are connected together.
Since I'm using RTK7RLG220C00000BJ, this connection is not performed and this is why SMS is not triggered. Is it correct what I'm saying?
Yes. I think that's the problem. also consider, not using more than 9 touch channel.
I copied exactly that example, but the board I'm using is RTK7RLG220C00000BJ and not RTK0EG0042S01001BJ.
Performing the physical connection now the SMS is working fine.
Now the issue is the power consumption.
I'm using RTK7RLG220C00000BJ board and I'm measuring the current as mentioned in the board manual, through header J11.
My amper-meter is measuring 36 mA which is far away from target (tens uA like mentioned in R01AN6847EJ0110 application note).
If I comment the qe_touch_main() routines, the consumption is 1.3 mA, and if I call the __stop() instruction, the consumption is 0.52 uA. I expect these values.
Is some peripheral consuming too much?
I attach the project so you can check the Smart Configurator.SMSWorking.zip
The touch peripheral is working with Snooze Mode Sequencer and the consumption now is 8.8 uA which is my target.
The problem was P21, if I set it as a digital output, the consumption increase to 20 mA.
Do you know why? Looking at the schematic board the pin is not connected to anything.
Hello simonemassignan.We're glad to hear that you've succeeded with running touch in snooze mode. Please confirm if my understanding of the situation is correct:Now, you have no problem with the power consumption and touch sensing in snooze mode, and a new issue is raised by enabling a GPIO that has no relation with the touch unit. Have you considered the wake-up signals? Are you sure the CPU remains in stop mode during the power consumption? As you mentioned, there's no connection between the P21 and any sink/source point. So, chances are an interrupt is waking up the CPU. Could you please test it and update the issue? (for example, changing the CPU clock and comparing current consumption) Regards.
Thanks for your reply, P21 is not configured as an interrupt, it is a simple GPIO, so I don't understand how an interrupt can wake up the microcontroller. The consumption is near 20 mA, in normal mode the consumption is 1.2 mA so I suppose there is something else that is running.
Anyway it is not a big deal since for my application I will use another part number and I will test there if there are unexpected behaviours.
That's somehow weird, Is it something specific about P21? can you try another GPIO?
Please keep us posted about that. Happy debugging.
It is specific to P21. Other GPIOs do not behave like that.
I was suspicious about the AVrefm alternate function of the P21, but it doesn't make sense when you're not using the ADC. Also, there's no errata about the problem.
Keep me posted after trying the new hardware.
I will test it on a different part number in my application (RL78 R7F102GBC2DNP). I will keep you updated if the behaviour is confirmed.