- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
Tool/software: Code Composer Studio
Hi,
I'm trying to determine how much power is consumed when copying two data buffers (~3KB in total) to/from SRAM <-> FRAM. I'm using memcpy to copy data between SRAM and FRAM, not using DMA.
I'm trying to use EnergyTrace (CCSv8) for this purpose. I have set markers in the code (e.g. toggling GPIO / output to UART etc.) but these markers are not seen in the Energy Trace power output (attached).
The initial spike seen is I think the clocks being setup ?, but where's the gpio toggling power consumption ?
The whole FRAM<->SRAM data transfer takes about 3ms each, so i've zoomed in the plot.
CPU is running in Active power mode. Energy trace is used in standalone mode.
Is there a better way to determine the power consumption for a FRAM read/write ?
Thank you
I have some code like the following:
/*
* main.c
*
*/
#include "conf.h"
#include "utils/myuart.h"
/*******************************************************
* Globals
*******************************************************/
unsigned char Buff_First[16*96];
unsigned char Buff_Second[16*96];
uint8_t *Buff_First_ptr = (uint8_t *)&Buff_First;
uint8_t *Buff_Second_ptr = (uint8_t *)&Buff_Second;
/*******************************************************
* FUNC DEFS
*******************************************************/
void benchmark_buff_checkpoint_latency(void);
/*************************************************************************************
* MAIN
*************************************************************************************/
void main(void)
{
/* mandatory init stuff */
WDTCTL = WDTPW | WDTHOLD; //Stop WDT
PM5CTL0 &= ~LOCKLPM5; // Disable the GPIO power-on default high-impedance mode to activate previously configured port settings
system_init(); // init clocks, UART
setupDebugPins(); // setup pins as output GPIO pins
benchmark_buff_checkpoint_latency();
while(1){
__no_operation();
}
}
/*************************************************************************************
* BENCHMARKING
*************************************************************************************/
void benchmark_buff_checkpoint_latency(void){
_DBGUART("aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa %d \r\n", 123);
_DBGUART("aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa %d \r\n", 123);
GPIO_toggleOutputOnPin( GPIO_PORT_P1, GPIO_PIN1 );
GPIO_toggleOutputOnPin( GPIO_PORT_P1, GPIO_PIN1 );
GPIO_toggleOutputOnPin( GPIO_PORT_P1, GPIO_PIN1 );
/* from SRAM to FRAM */
Buffer_backup(Buff_First_ptr, Buff_Second_ptr);
_DBGUART("aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa %d \r\n", 123);
_DBGUART("aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa %d \r\n", 123);
GPIO_toggleOutputOnPin( GPIO_PORT_P1, GPIO_PIN1 );
GPIO_toggleOutputOnPin( GPIO_PORT_P1, GPIO_PIN1 );
GPIO_toggleOutputOnPin( GPIO_PORT_P1, GPIO_PIN1 );
/* from FRAM to SRAM */
Buffer_restore(Buff_First_ptr, Buff_Second_ptr);
_DBGUART("aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa %d \r\n", 123);
_DBGUART("aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa %d \r\n", 123);
GPIO_toggleOutputOnPin( GPIO_PORT_P1, GPIO_PIN1 );
GPIO_toggleOutputOnPin( GPIO_PORT_P1, GPIO_PIN1 );
GPIO_toggleOutputOnPin( GPIO_PORT_P1, GPIO_PIN1 );
}
I guess the issue might be related with granularity ?
I proceeded with the following:
I ran the memcpy (SRAM <-> FRAM) iteratively for 1000 times as below:
for (i=0;i<1000;i++){
Buff_backup(Buff_First_ptr, Buff_Second_ptr); // copy both buff1 and buff2 to FRAM from SRAM using memcpy
}
same as above for reading back from FRAM to SRAM.
And I got the below.
According to this, FRAM write consumes much more power than FRAM reads.
FRAM write = ~1mW,
FRAM read = ~0.2mW
Am I reading this measurement correctly ?
Is there a way to find out the energy consumed during only the read/write periods ?
thanks
Hi Rosh,
Ok. Let's try this...in CCS on the menu on the top you can select View>Expressions to open an expressions window.
In the expression window, add your variable names and tell me what address they are located at.
I did something similar. See below. Notice that my variable 'buffer' is assigned to RAM. My other variable 'FRAM_buffer' is assigned to FRAM, but I had to use the #pragma PERSISTENT in order for the linker to place it there.
Also, take a look at the MSP430 FRAM Technology - How To and Best Practices.
Hi Dennis,
that is what I did as well. see code and screenshot attached, to confirm what you have said.
code:
#define BUFF_SIZE 16*96
// buffers in SRAM
unsigned char SRAM_Buff1[BUFF_SIZE];
unsigned char SRAM_Buff2[BUFF_SIZE];
// buffers in FRAM
#pragma PERSISTENT(FRAM_Buff1)
unsigned char FRAM_Buff1[BUFF_SIZE] = {0};
#pragma PERSISTENT(FRAM_Buff2)
unsigned char FRAM_Buff2[BUFF_SIZE] = {0};
memory locations:
.bss 0 00001c00 00000c94 UNINITIALIZED
00001c00 00000600 (.common:SRAM_Buff1)
00002200 00000600 (.common:SRAM_Buff2)
.TI.persistent
* 0 00004000 00000c02
00004000 00000600 main_pdi_exp_rawbenchmarking.obj (.TI.persistent:FRAM_Buff1)
00004600 00000600 main_pdi_exp_rawbenchmarking.obj (.TI.persistent:FRAM_Buff2)
confirmed the above locations in watch expressions as well. locations are as above.
Strange though, on the *.map file the length = 600 for the buffers, but in the CCS memory allocation window and the watch expressions windows show that the length = 1536 (BUFF_SIZE). why is *.map reporting differently ?
anyway, sticking to the topic, when I run the attached code, i get this :
FRAM Read energy is lower than FRAM Write, but speeds are the same.
same buffer size. using 1000 runs of memcpy.
Why is this ?
When I remove memcpy and simply copy data in a loop :
/* fram write */
for(i=0; i<1000; i++){
for (j=0;j<BUFF_SIZE;j++){
FRAM_Buff1[j]=SRAM_Buff1[j];
}
for (j=0;j<BUFF_SIZE;j++){
FRAM_Buff2[j]=SRAM_Buff2[j];
}
}
_delay(1000000);
/* fram read */
for(i=0; i<1000; i++){
for (j=0;j<BUFF_SIZE;j++){
SRAM_Buff1[j]=FRAM_Buff1[j];
}
for (j=0;j<BUFF_SIZE;j++){
SRAM_Buff2[j]=FRAM_Buff2[j];
}
}
I get the opposite behavior (reads consume more power than writes).. very strange..
of course, in the above (and also in the memcpy case), every FRAM read incurs a SRAM write and vice versa. but it still doesn't explain the asymmetric power consumption behavior.
Any thoughts ?
Hi Rosh,
I'm still waiting to hear back from our FRAM expert.
Regarding the references to the TA3 registers, I'm actually not sure, but it looks like the compiler is interpreting these as lower 64K relative addresses and happen to be the same address as some of the TA3 registers. The correct code is being generated, just a confusing disassembly.
Here is table from the datasheet:
**Attention** This is a public forum
