CC2538 + OpenMote energest problem

[bregell]

I wanted my power savings readings from my motes when using RDC to see how much time they spent in different phases. I got everything up and running and was happy until i looked at the actual readings. Readings:

Total Cycles	CPU	CPU %	LPM	LPM %	TX	TX %	RX	RX %
135651671	5207690	3,84%	130443981	96,16%	1958098	1.44%	9511601	7,01%

Total cycles is according to powertrace CPU + LPM as it is always in either mode.

The problem from what I can tell is that it is in TX + RX mode in more cycles than it spends in CPU mode. In my world this means that the radio is not turned of properly when going into LPM mode which would waste a lot of power.

Can somebody shed some light on this please :)

[g-oikonomou]

Could it be that some energest on/off is not getting toggled correctly in the RF driver?

You may also want to have a look at #967

[bregell]

Allready pached my repo with that pull request but tkx anyway. Now I have hooked up the OpenMote to a digital oscilloscope to measure the drawn current and from what I can see the timing values are: 125 msec waiting for package (current ~25mA) and then 875 msec in LPM0 (current ~5 mA). This would give a total of 12.5 % in CPU mode. However now it seems like CPU+RX+TX is ~12.5% which cunfuses me as from what I can tell in the code with energest states there is nothing wrong. Also the device never enters either LPM1 or LPM2 which aslo is a bit confusing. FYI I am using the Drowsie RDC driver in my project which uses ctimer for sheduling can this be an issue?

[g-oikonomou]

Not familiar with drowsie at all.

Under ContikiMAC you'd see a CCA spike every approximately 125ms, with smaller wake up spikes in between and deep sleep otherwise.

The numbers you mention are very high, I'd expect uA under deep sleep.

Does the code think it enters LPM2?

Some thoughts: Connected JTAG could be preventing it, I need to check the UG again. The code will not deep sleep if the RF or USB is on. Other modules can also prevent deep sleep if configured to do so.

I suspect there could be a bug in the power down code somewhere.

[g-oikonomou]

Also: the code will refuse to put the chip in deep sleep unless there is a scheduled sleep timer interrupt to wake us up. This is set by rtimers. Running drowsie means you won't have such rtimer and lpm will select pm0

[bregell]

From what I can see ContikiMAC uses rtimer and that is basicly the only difference. They both wake up 8 times a second and then listens for a while and then goes back to sleep if nothing is in the air at that time.

I have maid a CoAP resource that runs on a OpenBattery platform

snprintf(
      (char *)buffer, REST_MAX_CHUNK_SIZE, 
      "CPU:%d.%d%%, LPM:%d.%d%%, PM0:%u, PM1:%u, PM2:%u", 
      cpu_f, cpu_d,
      lpm_f, lpm_d, 
      (int)LPM_STATS_GET(0),
      (int)LPM_STATS_GET(1), 
      (int)LPM_STATS_GET(2)
    );

This returns the amount of precent in either CPU or LPM and the amount of cykles in each LPM mode and LPM1 and 2 are at zero. While LPM0 scales with time ofc.

Then I will modify the Drowsie driver to use rtimer instead and hope that that sloves the problems!

[g-oikonomou]

That's 99% certainly the reason.

Also forget what I said about small spikes in between, too much cc26xx lately confused me :s Apologies

[g-oikonomou]

@bregell Johan, where are we on this one?

I ran some tests with standard CC2538DK (udp-echo-server) and I can confirm that the SoC is dropping to LPM2: ~300uA consumption between CCA spikes. Arguably, this is a little too high, but it does drop.

[bregell]

Yeah I have managed to get it sleep now so that's A-OK! However the Energest calculations are still off and that annoys me. I have gone trough all the from what I can tell relevant parts of the code, especially the cc2538-rf files.

[adamdunkels]

I may be misunderstanding things, but when you say that the energest calculations are off, I'm guessing you refer to your earlier comment about the RF stats being higher than the CPU stats? This is in fact something normal: this just indicates that the radio is turned on more than the CPU. The most extreme example is when running with the radio turned on all the time. The RF would then be 100% and the CPU, say, 5%.

For an SoC like the CC2538, this may sound strange as the CPU would probably not reach a low-power LPM state when the radio is turned on, but the energest module doesn't know about how this is implemented by the SoC. Think of the CPU and the RF module as being completely separate.

[bregell]

Okay, so when reading more carefully in lpm.c it clearly states that the RF module can be on when the CPU is in LPM 0. To conclude, the total amount of cycles is still CPU+LPM. The total amount of cycles the RF can be on is CPU+LPM0 and the rest of the cycles is LPM1+LPM2.
However this helped me with other issues too so no harm done :)