R7F102GGE2DFB RL78/G22 fast prototyping board - current consumption measurement

Hello simonemassignan,

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 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,
Jef

If this response, or one provided by another user, answers your question, please verify the answer. Thank you!
Renesas Engineering Community Moderators
https://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) ?

Thanks

TouchProject.zip

I want to use the snooze mode sequencer as the example attached. 

The application does not exit standby mode, I think the CTSU does not trigger the measure because the timer interrupt does not occurr.

This is where the firmware stucks, on stop() instruction.

This is the timer configuration.

After timer starts, ITLS00 register is set to 1 (see image below), so I think the compare match signal has been detected in channel 0.

Update on my work:

The following routine is called in main loop and it's working, just to demonstrate that timer overflows,

then CTSU start measurement and gives a callback when the measure end.

The problem is that I want to use the Snooze mode sequencer to reach the lowest power consumption

and it is not working for me.

********************************************************************

***************** WORKING *************************************

********************************************************************

static void r_rssk_touch_stop_mode(void)
{
fsp_err_t err;

/* TAU0 power off */
PER0 &= 0xFEU;

/* Change interval time for STOP mode */
R_Config_ITL000_SetInterval(TOUCH_STOP_SCAN_INTERVAL);

/* Clear interrupt flag */
ITLS0 &= (uint8_t)~_01_ITL_CHANNEL0_COUNT_MATCH_DETECTE;

/* Scan start */
err = RM_TOUCH_ScanStart(g_qe_touch_instance_config02.p_ctrl);

if (FSP_SUCCESS != err)
{
while (true) {}
}

/* Settings for returning from low power mode */
R_Config_ITL000_Start();

while (true)
{
/* Wait for CTSU to finish processing */
while (true)
{
__stop();

if (1U == g_qe_touch_flag)
{
break;
}
}

/* Clear interrupt flag */
ITLS0 &= (uint8_t)~_01_ITL_CHANNEL0_COUNT_MATCH_DETECTE;

/* Clear the flag indicating that CTSU processing is complete. */
g_qe_touch_flag = 0U;

/* Get the scanned data */
err = RM_TOUCH_DataGet(g_qe_touch_instance_config02.p_ctrl, &button_status, NULL, NULL);

// I'm not yet interested on the data

R_Config_ITL000_Stop();
break;

}
}

*********************************************************************************************

****************** NOT WORKING *******************************************************

*********************************************************************************************

static void r_rssk_touch_stop_mode(void)
{
fsp_err_t err;

/* TAU0 power off */
PER0 &= 0xFEU;

/* Turn off LEDs */
LED3 = LED_OFF;
r_rssk_touch_led_clear();

/* Change interval time for STOP mode */
R_Config_ITL000_SetInterval(TOUCH_STOP_SCAN_INTERVAL);

/* Clear interrupt flag */
ITLS0 &= (uint8_t)~_01_ITL_CHANNEL0_COUNT_MATCH_DETECTE;

/* SMS setting */
err = RM_TOUCH_SmsSet(g_qe_touch_instance_config02.p_ctrl);

if (FSP_SUCCESS != err)
{
while (true) {}
}

/* Scan start */
err = RM_TOUCH_ScanStart(g_qe_touch_instance_config02.p_ctrl);

if (FSP_SUCCESS != err)
{
while (true) {}
}

/* Settings for returning from low power mode */
INTC_Start();
R_Config_ITL000_Start();

while (true)
{
/* Wait for CTSU to finish processing */
while (true)
{
__stop();

if (1U == g_qe_touch_flag)
{
break;
}
}
/* Clear interrupt flag */
ITLS0 &= (uint8_t)~_01_ITL_CHANNEL0_COUNT_MATCH_DETECTE;

/* Clear the flag indicating that CTSU processing is complete. */
g_qe_touch_flag = 0U;

/* Get the scanned data */
err = RM_TOUCH_DataGet(g_qe_touch_instance_config02.p_ctrl, &button_status, NULL, NULL);

if (FSP_SUCCESS == err)
{
if (0U != button_status)
{
/* Transition to NORMAL mode */
INTC_Stop();
R_Config_ITL000_Stop();
break; // ----> reaches r_rssk_touch_normal_mode() routine
}
}
}
}

I'm not sure how the SMS works.

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:

https://www.renesas.com/us/en/document/apn/rl78-family-ctsu-module-software-integration-system

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. 

https://www.renesas.com/us/en/document/apn/rl78g22-capacitive-touch-low-power-guide-sms-mec-function-rev110

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. 

Yes. I think that's the problem. also consider, not using more than 9 touch channel. 

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

Update: 

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.

Thanks.

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.

Best wishes

I will test it on a different part number in my application (RL78 R7F102GBC2DNP). I will keep you updated if the behaviour is confirmed.