RIOT is saw-toothing in energy consumption (even when idling) #5009

miri64 · 2016-03-09T08:46:14Z

I after I encountered the same problems mentioned by @PeterKietzmann in this thread when conducting the experiments for my thesis I did some experiments independent from that. I post this as a RIOT issue since according to Peter, the IoT-LAB tutorials do not produce this kind of output so this might be a RIOT problem.

I used the energy consumption monitoring feature of the IoT-LAB to measure with a period of 140 μs and an average of 4.

I used to setups:

First, I setup an application that went into main and left it immediately for idling:

int main(void) {
    return 0;
}

I did not add any other modules to the binary and disabled auto_init (so no xtimer or anything is running in the background).

The energy consumption for this looks as follows:

Also with an disabled auto_init I had another application running which remained in main()

int main(void) {
    while(1);
    return 0;
}

The spurious peaks are a known IoT-LAB issue: iot-lab/iot-lab#148, the saw-toothing however is not. The frequency of the tooths isn't constant and differs from experiment to experiment. They can be very long or very short (as seen above with my two experiments), but up until now they always were more likely in a resolution of seconds, not milli- or microseconds.

The text was updated successfully, but these errors were encountered:

jnohlgard · 2016-03-09T09:27:41Z

I have seen this same sawtooth in RIOT on Mulle with local measurements as well so it's also not limited to the iotlab-m3 boards. I get a more or less horizontal line idling in Contiki.

emmanuelsearch · 2016-03-09T14:25:59Z

@gebart a stupid question: you did use the same measurement tools/techniques for both RIOT and Contiki on mulle, right?

jnohlgard · 2016-03-09T14:55:21Z

yes, even the same board and connections, I only reflashed a new image on the Mulle between the tests. But this was probably 6 months ago, and I don't know where I put the data sets from the measurement.

miri64 · 2016-03-09T17:02:23Z

For reference: here is the application I used to generate above plots. The idling state can be achieved by setting the environment variable IDLE to a non-zero value.

miri64 · 2016-03-09T17:06:34Z

And here is the link ^^: https://github.com/authmillenon/RIOT_playground/tree/master/empty

LudwigKnuepfer · 2016-03-09T18:48:32Z

I have seen this same sawtooth in RIOT on Mulle with local measurements as well so it's also not limited to the iotlab-m3 boards. I get a more or less horizontal line idling in Contiki.

@gebart May I ask which value this line resides at?

jnohlgard · 2016-03-09T18:52:17Z

@LudwigKnuepfer depends on low power mode settings in the Contiki port, but anything from 40 uA to a few mA (radio listening and cpu awake idle).

jnohlgard · 2016-03-09T18:55:57Z

@LudwigKnuepfer I just had an idea, could it be transceiver related?
Is there any analog filter on the measured signal in the IoT-lab?

miri64 · 2016-03-09T19:16:44Z

Not to say this should not be investigated, but are you sure? In my experiments I did not initialize anything, so why should the transceiver pull power?

miri64 · 2016-03-09T19:18:00Z

(though this might be the easily testable with a transceiver-less board as an arduino-due e.g.)

malosek · 2016-03-10T22:32:18Z

Hello,

Have made quick test using MSP430F2618 loaded in ts430pm64 and checked via energy trace feature of msp-fet in ccs.

1HMz internal DCO

8MHz internal DCO

can not see any sawtooth wave there, have just while (1); in the main wo autoinit.
why do you think is riot related? since while(1); is just something like
0x1c48: 3FFF JMP (0x1c48)
so wo xtimer there is no scheduler involved and CPU runs always at full speed/power.

interesting would be to know if the sawtooth freq is dependent from MPU freq of if changing int/ext oscillator makes some difference.

PS: for me it smells like some charge is build somewhere (on some floating cap) and when reaching critical value - is discharged. Or maybe some un-initialized peripheral? So I would rather look around the MCU then inside.

wbr
malo

miri64 · 2016-03-10T22:36:16Z

why do you think is riot related?

Because Contiki on the same hardware (Cortex-M in @gebart and my case) does not show this kind of behavior. Even if it is some dangling peripherals that is a problem that should be fixed IMHO.

malosek · 2016-03-10T23:24:58Z

Hello,

so you have exactly the same port settings "while" looping in the "while" compared to contiki and with riot you are getting sawtooth in power consumption?

wbr
malo

miri64 · 2016-03-10T23:28:03Z

I'm just the messenger. @PeterKietzmann and @gebart had ;-)

jnohlgard · 2016-03-11T06:37:31Z

The measurements that I did before were made with the RIOT scheduler alive, but only idling, which is more useful for my purposes than measuring an empty while(1); loop. The same was done for Contiki, the application is idling waiting for an event (an etimer with a 60 second timeout was queued). Foremost I am interested in getting a longer device life time on battery, so I want the application to be idle but still responsive.

jnohlgard · 2016-03-11T06:42:07Z

It could be some pin floating and building up a charge which makes it leech less and less until floats low enough to trigger some piece inside a device which would let it discharge again, like @malosek suggested, but this is pure speculation. I also believe we should look outside the MCU for starters, turn off peripherals and make sure nothing is floating. The common denominator between mulle and iotlab-m3 is that they both have an at86rf2xx radio so I'd begin checking that. I don't have any time right now to do these measurements though.

malosek · 2016-03-14T00:13:00Z

Hello,

yes is pure speculation, since I did not even see the schematics, but the period of tooth saw is quite long which makes me quite curious what it can be. are you 100% sure with your measurement setup?
Anyway do not have the measurement setup with enough bw and resolution to measure MCU in some low power state and waking up just on timer overflow for few cycles and go to low power again.
But have made measurement with toggling led each 500ms - no sign of tooth saw (8MHz int DCO)

Will try to get some reasonable setup to measure wo the led.
wbr
malo

RIOT-2016.10 - Release Notes ============================ RIOT is a real-time multi-threading operating system that supports a range of devices that are typically found in the Internet of Things: 8-bit microcontrollers, 16-bit microcontrollers and light-weight 32-bit processors. RIOT is based on the following design principles: energy-efficiency, real-time capabilities, small memory footprint, modularity, and uniform API access, independent of the underlying hardware (this API offers partial POSIX compliance). RIOT is developed by an international open source community which is independent of specific vendors (e.g. similarly to the Linux community) and is licensed with a non-viral copyleft license (LGPLv2.1), which allows indirect business models around the free open-source software platform provided by RIOT. About this release: =================== This release provides a lot of new features as well as it fixes several major bugs. Among these new features are the new simplified network socket API called sock, the GNRC specific CoAP implementation gcoap and several new packages: TinyDTLS, the Aversive++ microcontroller library for robotics, the u8g2 graphic library, and nanocoap. Using the new sock API an implementation of the Simple Time Network Protocol (SNTP) was also introduced, allowing for time synchronization between nodes. New platforms include the Arduino Uno, the Arduino Duemilanove, the Arduino Zero, SODAQ Autonomo, and the Zolertia remote (rev. B). The most significant bug fix was done in native which led to a significantly more robust handling of ISRs and now allows for at least 1,000 native instances running stably on one machine. About 263 pull requests with about 398 commits have been merged since the last release and about 42 issues have been solved. 37 people contributed with code in 100 days. 1006 files have been touched with 166500 insertions and 26926 deletions. Notations used below: ===================== + means new feature/item * means modified feature/item - means removed feature/item New features and changes ======================== General ------- * Verbose behavior for assert() macro Core ---- + MPU support for Cortex-M API changes ----------- + Socket-like sock API (replacing conn) * netdev2: Add Testmodes and CCA modes * IEEE 802.15.4: clean-up Intra-PAN behavior * IEEE 802.15.4: centralize default values * gnrc_pktbuf: allow for 0-sized snips + gnrc_netapi: mbox and arbitrary callback support System libraries ---------------- No new features or changes Networking ---------- + Provide sock-port for GNRC + gcoap: a GNRC-based CoAP implementation + Simple Network Time Protocol (RFC 5905, section 14) + Priority Queue for packet snips + IPv4 header definitions Packages -------- + nanocoap: CoAP header parser/builder + TinyDTLS: DTLS library + tiny-asn1: asn.1/der decoder + Aversive++ microcontroller programming library + u8g2 graphic library Platforms --------- + Support for stm32f2xx MCU family + Low power modes for samd21 CPUs + More Arduino-based platforms: + Arduino Uno + Arduino Duemilanove + Arduino Zero + More boards of ST's Nucleo platforms: + ST Nucleo F030 board support + ST Nucleo F070 board support + ST Nucleo F446 board support + SODAQ Automono + Zolertia remote rev. B Drivers ------- + W5100 Ethernet device + Atmel IO1 Xplained extension + LPD8808 LED strips * at86rf2xx: provide capability to access the RND_VALUE random value register Build System ------------ + static-tests build target for easy local execution of CI's static tests Other ----- + Provide Arduino API to Nucleo boards + Packer configuration file to build vagrant boxes + CC2650STK Debugger Support + ethos: add Ethos over TCP support Fixed Issues from the last release ================================== #534: native debugging on osx fails #2071: native: *long* overdue fixes #3341: netdev2_tap crashes when hammered #5007: gnrc icmpv6: Ping reply goes out the wrong interface #5432: native: valgrind fails Known Issues ============ Networking related issues ------------------------- #3075: nhdp: unnecessary microsecond precision: NHDP works with timer values of microsecond precision which is not required. Changing to lower precision would save some memory. #4048: potential racey memory leak: According to the packet buffer stats, flood-pinging a multicast destination may lead to a memory leak due to a race condition. However, it seems to be a rare case and a completely filled up packet buffer was not observed. #4388: POSIX sockets: open socket is bound to a specific thread: This was an inherit problem of the conn API under GNRC. Since the POSIX sockets are still based on conn for this release, this issue persists #4527: gnrc_ipv6: Multicast is not forwarded if routing node listens to the address (might still be fixable for release, see #5729, #5230: gnrc ipv6: multicast packets are not dispatched to the upper layers) #5016: gnrc_rpl: Rejoining RPL instance as root after reboot messes up routing #5055: cpuid: multiple radios will get same EUI-64 Nodes with multiple interfaces might get the same EUI-64 for them since they are generated from the same CPU ID. #5656: Possible Weakness with locking in the GNRC network stack: For some operations mutexes to the network interfaces need to get unlocked in the current implementation to not get deadlocked. Recursive mutexes as provided in #5731 might help to solve this problem. #5748: gnrc: nodes crashing with too small packet buffer: A packet buffer of size ~512 B might lead to crashes. The issue describes this for several hundret nodes, but agressive flooding with just two nodes was also shown to lead to this problem. #5858: gnrc: 6lo: potential problem with reassembly of fragments: If one frame gets lost the reassembly state machine might get out of sync ### NDP is not working properly #4499: handle of l2src_len in gnrc_ndp_rtr_sol_handle: Reception of a router solicitation might lead to invalid zero-length link-layer addresses in neighbor cache. #5005: ndp: router advertisement sent with global address: Under some circumstances a router might send RAs with GUAs. While they are ignored on receive (as RFC 4861 specifies), RAs should have link-local addresses and not even be send out this way. #5122: NDP: global unicast address on non-6LBR nodes disappears after a while: Several issues (also see #5760) lead to a global unicast address effectively being banned from the network (disappears from neighbor cache, is not added again) #5467: ipv6 address vanishes when ARO (wrongly) indicates DUP caused by outdated ncache at router #5539: Border Router: packet not forwarded from ethos to interface 6 #5790: ND: Lost of Global IPV6 on node after sending lot of UDP frame from BR Timer related issues -------------------- #4841: xtimer: timer already in the list: Under some conditions an xtimer can end up twice in the internal list of the xtimer module #4902: xtimer: xtimer_set: xtimer_set does not handle integer overflows well #5338: xtimer: xtimer_now() not ISR safe for non-32-bit platforms. #5928: xtimer: usage in board_init() crashes: some boards use the xtimer in there board_init() function. The xtimer is however first initialized in the auto_init module which is executed after board_init() #6052: tests: xtimer_drift gets stuck: xtimer_drift application freezes after ~30-200 seconds native related issues --------------------- #495: native not float safe: When the FPU is used when an asynchronous context switch occurs, either the stack gets corrupted or a floating point exception occurs. #2175: ubjson: valgind registers "Invalid write of size 4" in unittests #4590: pkg: building relic with clang fails. #5796: native: tlsf: early malloc will lead to a crash: TLSF needs pools to be initialized (which is currently expected to be done in an application). If a malloc is needed before an application's main started (e.g. driver initialization) the node can crash, since no pool is allocated yet. other platform related issues ----------------------------- #1891: newlib-nano: Printf formatting does not work properly for some numberic types: PRI[uxdi]64, PRI[uxdi]8 and float are not parsed in newlib-nano #2006: cpu/nrf51822: timer callback may be fired too early #2143: unittests: tests-core doesn't compile for all platforms: GCC build-ins were used in the unittests which are not available with msp430-gcc #2300: qemu unittest fails because of a page fault #4512: pkg: tests: RELIC unittests fail on iotlab-m3 #4522: avsextrem: linker sometimes doesn't find `bl_init_clks()` #4560: make: clang is more pedantic than gcc oonf_api is not building with clang. (Partly solved by #4593) #4694: drivers/lm75a: does not build #4737: cortex-m: Hard fault after a thread exits (under some circumstances) #4822: kw2xrf: packet loss when packets get fragmented #4876: at86rf2xx: Simultaneous use of different transceiver types is not supported #4954: chronos: compiling with -O0 breaks #4866: not all GPIO driver implementations are thread safe: Due to non-atomic operations in the drivers some pin configurations might get lost. #5009: RIOT is saw-toothing in energy consumption (even when idling) #5103: xtimer: weird behavior of tests/xtimer_drift: xtimer_drift randomly jumps a few seconds on nrf52 #5361: cpu/cc26x0: timer broken #5405: Eratic timings on iotlab-m3 with compression context activated #5460: cpu/samd21: i2c timing with compiler optimization #5486: at86rf2xx: lost interrupts #5489: cpu/lpc11u34: ADC broken #5603: atmega boards second UART issue #5678: at86rf2xx: failed assertion in _isr #5719: cc2538: rf driver doesn't handle large packets #5799: kw2x: 15.4 duplicate transmits #5944: msp430: ipv6_hdr unittests fail #5848: arduino: Race condition in sys/arduino/Makefile.include #5954: nRF52 uart_write get stuck #6018: nRF52 gnrc 6lowpan ble memory leak other issues ------------ #1263: TLSF implementation contains (a) read-before-write error(s). #3256: make: Setting constants on compile time doesn't really set them everywhere #3366: periph/i2c: handle NACK #4488: Making the newlib thread-safe: When calling puts/printf after thread_create(), the CPU hangs for DMA enabled uart drivers. #4866: periph: GPIO drivers are not thread safe #5128: make: buildtest breaks when exporting FEATURES_PROVIDED var #5207: make: buildest fails with board dependent application Makefiles #5390: pkg: OpenWSN does not compile: This package still uses deprecated modules and was not tested for a long time. #5520: tests/periph_uart not working #5561: C++11 extensions in header files #5776: make: Predefining CFLAGS are parsed weirdly #5863: OSX + SAMR21-xpro: shell cannot handle command inputs larger than 64 chars #5962: Makefile: UNDEF variable is not working as documented #6022: pkg: build order issue Special Thanks ============== We like to give our special thanks to all the companies that provided us with their hardware for porting and testing, namely the people from (in alphabeticalorder): Atmel, Freescale, Imagination Technologies, Limifrog, Nordic, OpenMote, Phytec, SiLabs, UDOO,and Zolertia; and also companies that directly sponsored development time: Cisco Systems, Eistec, Ell-i, Enigeering Spirit, Nordic, FreshTemp LLC, OTAkeys and Phytec. More information ================ http://www.riot-os.org Mailing lists ------------- * RIOT OS kernel developers list devel@riot-os.org (http://lists.riot-os.org/mailman/listinfo/devel) * RIOT OS users list users@riot-os.org (http://lists.riot-os.org/mailman/listinfo/users) * RIOT commits commits@riot-os.org (http://lists.riot-os.org/mailman/listinfo/commits) * Github notifications notifications@riot-os.org (http://lists.riot-os.org/mailman/listinfo/notifications) IRC --- * Join the RIOT IRC channel at: irc.freenode.net, #riot-os License ======= * Most of the code developed by the RIOT community is licensed under the GNU Lesser General Public License (LGPL) version 2.1 as published by the Free Software Foundation. * Some external sources are published under a separate, LGPL compatible license (e.g. some files developed by SICS). All code files contain licensing information.

RIOT-2016.10 - Release Notes ============================ RIOT is a real-time multi-threading operating system that supports a range of devices that are typically found in the Internet of Things: 8-bit microcontrollers, 16-bit microcontrollers and light-weight 32-bit processors. RIOT is based on the following design principles: energy-efficiency, real-time capabilities, small memory footprint, modularity, and uniform API access, independent of the underlying hardware (this API offers partial POSIX compliance). RIOT is developed by an international open source community which is independent of specific vendors (e.g. similarly to the Linux community) and is licensed with a non-viral copyleft license (LGPLv2.1), which allows indirect business models around the free open-source software platform provided by RIOT. About this release: =================== This release provides a lot of new features as well as it fixes several major bugs. Among these new features are the new simplified network socket API called sock, the GNRC specific CoAP implementation gcoap and several new packages: TinyDTLS, the Aversive++ microcontroller library for robotics, the u8g2 graphic library, and nanocoap. Using the new sock API an implementation of the Simple Time Network Protocol (SNTP) was also introduced, allowing for time synchronization between nodes. New platforms include the Arduino Uno, the Arduino Duemilanove, the Arduino Zero, SODAQ Autonomo, and the Zolertia remote (rev. B). The most significant bug fix was done in native which led to a significantly more robust handling of ISRs and now allows for at least 1,000 native instances running stably on one machine. About 263 pull requests with about 398 commits have been merged since the last release and about 42 issues have been solved. 37 people contributed with code in 100 days. 1006 files have been touched with 166500 insertions and 26926 deletions. Notations used below: ===================== + means new feature/item * means modified feature/item - means removed feature/item New features and changes ======================== General ------- * Verbose behavior for assert() macro Core ---- + MPU support for Cortex-M API changes ----------- + Socket-like sock API (replacing conn) * netdev2: Add Testmodes and CCA modes * IEEE 802.15.4: clean-up Intra-PAN behavior * IEEE 802.15.4: centralize default values * gnrc_pktbuf: allow for 0-sized snips + gnrc_netapi: mbox and arbitrary callback support System libraries ---------------- No new features or changes Networking ---------- + Provide sock-port for GNRC + gcoap: a GNRC-based CoAP implementation + Simple Network Time Protocol (RFC 5905, section 14) + Priority Queue for packet snips + IPv4 header definitions Packages -------- + nanocoap: CoAP header parser/builder + TinyDTLS: DTLS library + tiny-asn1: asn.1/der decoder + Aversive++ microcontroller programming library + u8g2 graphic library Platforms --------- + Support for stm32f2xx MCU family + Low power modes for samd21 CPUs + More Arduino-based platforms: + Arduino Uno + Arduino Duemilanove + Arduino Zero + More boards of ST's Nucleo platforms: + ST Nucleo F030 board support + ST Nucleo F070 board support + ST Nucleo F446 board support + SODAQ Automono + Zolertia remote rev. B Drivers ------- + W5100 Ethernet device + Atmel IO1 Xplained extension + LPD8808 LED strips * at86rf2xx: provide capability to access the RND_VALUE random value register Build System ------------ + static-tests build target for easy local execution of CI's static tests Other ----- + Provide Arduino API to Nucleo boards + Packer configuration file to build vagrant boxes + CC2650STK Debugger Support + ethos: add Ethos over TCP support Fixed Issues from the last release ================================== RIOT-OS#534: native debugging on osx fails RIOT-OS#2071: native: *long* overdue fixes RIOT-OS#3341: netdev2_tap crashes when hammered RIOT-OS#5007: gnrc icmpv6: Ping reply goes out the wrong interface RIOT-OS#5432: native: valgrind fails Known Issues ============ Networking related issues ------------------------- RIOT-OS#3075: nhdp: unnecessary microsecond precision: NHDP works with timer values of microsecond precision which is not required. Changing to lower precision would save some memory. RIOT-OS#4048: potential racey memory leak: According to the packet buffer stats, flood-pinging a multicast destination may lead to a memory leak due to a race condition. However, it seems to be a rare case and a completely filled up packet buffer was not observed. RIOT-OS#4388: POSIX sockets: open socket is bound to a specific thread: This was an inherit problem of the conn API under GNRC. Since the POSIX sockets are still based on conn for this release, this issue persists RIOT-OS#4527: gnrc_ipv6: Multicast is not forwarded if routing node listens to the address (might still be fixable for release, see RIOT-OS#5729, RIOT-OS#5230: gnrc ipv6: multicast packets are not dispatched to the upper layers) RIOT-OS#5016: gnrc_rpl: Rejoining RPL instance as root after reboot messes up routing RIOT-OS#5055: cpuid: multiple radios will get same EUI-64 Nodes with multiple interfaces might get the same EUI-64 for them since they are generated from the same CPU ID. RIOT-OS#5656: Possible Weakness with locking in the GNRC network stack: For some operations mutexes to the network interfaces need to get unlocked in the current implementation to not get deadlocked. Recursive mutexes as provided in RIOT-OS#5731 might help to solve this problem. RIOT-OS#5748: gnrc: nodes crashing with too small packet buffer: A packet buffer of size ~512 B might lead to crashes. The issue describes this for several hundret nodes, but agressive flooding with just two nodes was also shown to lead to this problem. RIOT-OS#5858: gnrc: 6lo: potential problem with reassembly of fragments: If one frame gets lost the reassembly state machine might get out of sync ### NDP is not working properly RIOT-OS#4499: handle of l2src_len in gnrc_ndp_rtr_sol_handle: Reception of a router solicitation might lead to invalid zero-length link-layer addresses in neighbor cache. RIOT-OS#5005: ndp: router advertisement sent with global address: Under some circumstances a router might send RAs with GUAs. While they are ignored on receive (as RFC 4861 specifies), RAs should have link-local addresses and not even be send out this way. RIOT-OS#5122: NDP: global unicast address on non-6LBR nodes disappears after a while: Several issues (also see RIOT-OS#5760) lead to a global unicast address effectively being banned from the network (disappears from neighbor cache, is not added again) RIOT-OS#5467: ipv6 address vanishes when ARO (wrongly) indicates DUP caused by outdated ncache at router RIOT-OS#5539: Border Router: packet not forwarded from ethos to interface 6 RIOT-OS#5790: ND: Lost of Global IPV6 on node after sending lot of UDP frame from BR Timer related issues -------------------- RIOT-OS#4841: xtimer: timer already in the list: Under some conditions an xtimer can end up twice in the internal list of the xtimer module RIOT-OS#4902: xtimer: xtimer_set: xtimer_set does not handle integer overflows well RIOT-OS#5338: xtimer: xtimer_now() not ISR safe for non-32-bit platforms. RIOT-OS#5928: xtimer: usage in board_init() crashes: some boards use the xtimer in there board_init() function. The xtimer is however first initialized in the auto_init module which is executed after board_init() RIOT-OS#6052: tests: xtimer_drift gets stuck: xtimer_drift application freezes after ~30-200 seconds native related issues --------------------- RIOT-OS#495: native not float safe: When the FPU is used when an asynchronous context switch occurs, either the stack gets corrupted or a floating point exception occurs. RIOT-OS#2175: ubjson: valgind registers "Invalid write of size 4" in unittests RIOT-OS#4590: pkg: building relic with clang fails. RIOT-OS#5796: native: tlsf: early malloc will lead to a crash: TLSF needs pools to be initialized (which is currently expected to be done in an application). If a malloc is needed before an application's main started (e.g. driver initialization) the node can crash, since no pool is allocated yet. other platform related issues ----------------------------- RIOT-OS#1891: newlib-nano: Printf formatting does not work properly for some numberic types: PRI[uxdi]64, PRI[uxdi]8 and float are not parsed in newlib-nano RIOT-OS#2006: cpu/nrf51822: timer callback may be fired too early RIOT-OS#2143: unittests: tests-core doesn't compile for all platforms: GCC build-ins were used in the unittests which are not available with msp430-gcc RIOT-OS#2300: qemu unittest fails because of a page fault RIOT-OS#4512: pkg: tests: RELIC unittests fail on iotlab-m3 RIOT-OS#4522: avsextrem: linker sometimes doesn't find `bl_init_clks()` RIOT-OS#4560: make: clang is more pedantic than gcc oonf_api is not building with clang. (Partly solved by RIOT-OS#4593) RIOT-OS#4694: drivers/lm75a: does not build RIOT-OS#4737: cortex-m: Hard fault after a thread exits (under some circumstances) RIOT-OS#4822: kw2xrf: packet loss when packets get fragmented RIOT-OS#4876: at86rf2xx: Simultaneous use of different transceiver types is not supported RIOT-OS#4954: chronos: compiling with -O0 breaks RIOT-OS#4866: not all GPIO driver implementations are thread safe: Due to non-atomic operations in the drivers some pin configurations might get lost. RIOT-OS#5009: RIOT is saw-toothing in energy consumption (even when idling) RIOT-OS#5103: xtimer: weird behavior of tests/xtimer_drift: xtimer_drift randomly jumps a few seconds on nrf52 RIOT-OS#5361: cpu/cc26x0: timer broken RIOT-OS#5405: Eratic timings on iotlab-m3 with compression context activated RIOT-OS#5460: cpu/samd21: i2c timing with compiler optimization RIOT-OS#5486: at86rf2xx: lost interrupts RIOT-OS#5489: cpu/lpc11u34: ADC broken RIOT-OS#5603: atmega boards second UART issue RIOT-OS#5678: at86rf2xx: failed assertion in _isr RIOT-OS#5719: cc2538: rf driver doesn't handle large packets RIOT-OS#5799: kw2x: 15.4 duplicate transmits RIOT-OS#5944: msp430: ipv6_hdr unittests fail RIOT-OS#5848: arduino: Race condition in sys/arduino/Makefile.include RIOT-OS#5954: nRF52 uart_write get stuck RIOT-OS#6018: nRF52 gnrc 6lowpan ble memory leak other issues ------------ RIOT-OS#1263: TLSF implementation contains (a) read-before-write error(s). RIOT-OS#3256: make: Setting constants on compile time doesn't really set them everywhere RIOT-OS#3366: periph/i2c: handle NACK RIOT-OS#4488: Making the newlib thread-safe: When calling puts/printf after thread_create(), the CPU hangs for DMA enabled uart drivers. RIOT-OS#4866: periph: GPIO drivers are not thread safe RIOT-OS#5128: make: buildtest breaks when exporting FEATURES_PROVIDED var RIOT-OS#5207: make: buildest fails with board dependent application Makefiles RIOT-OS#5390: pkg: OpenWSN does not compile: This package still uses deprecated modules and was not tested for a long time. RIOT-OS#5520: tests/periph_uart not working RIOT-OS#5561: C++11 extensions in header files RIOT-OS#5776: make: Predefining CFLAGS are parsed weirdly RIOT-OS#5863: OSX + SAMR21-xpro: shell cannot handle command inputs larger than 64 chars RIOT-OS#5962: Makefile: UNDEF variable is not working as documented RIOT-OS#6022: pkg: build order issue Special Thanks ============== We like to give our special thanks to all the companies that provided us with their hardware for porting and testing, namely the people from (in alphabeticalorder): Atmel, Freescale, Imagination Technologies, Limifrog, Nordic, OpenMote, Phytec, SiLabs, UDOO,and Zolertia; and also companies that directly sponsored development time: Cisco Systems, Eistec, Ell-i, Enigeering Spirit, Nordic, FreshTemp LLC, OTAkeys and Phytec. More information ================ http://www.riot-os.org Mailing lists ------------- * RIOT OS kernel developers list devel@riot-os.org (http://lists.riot-os.org/mailman/listinfo/devel) * RIOT OS users list users@riot-os.org (http://lists.riot-os.org/mailman/listinfo/users) * RIOT commits commits@riot-os.org (http://lists.riot-os.org/mailman/listinfo/commits) * Github notifications notifications@riot-os.org (http://lists.riot-os.org/mailman/listinfo/notifications) IRC --- * Join the RIOT IRC channel at: irc.freenode.net, #riot-os License ======= * Most of the code developed by the RIOT community is licensed under the GNU Lesser General Public License (LGPL) version 2.1 as published by the Free Software Foundation. * Some external sources are published under a separate, LGPL compatible license (e.g. some files developed by SICS). All code files contain licensing information.

roberthartung · 2020-06-30T12:46:19Z

I can grab a STM nucleo board (hopefully tomorrow) and verify the latest power consumption behavior.

roberthartung · 2020-07-08T07:17:05Z

@miri64 Got the nucleo-l476rg here with me. I am measuring with a Keithley DMM7510. I just downloaded the CSV and plotted with gnuplot for now; I can't see saw-toothing here. My code is the same as what you did (main that does to idle).

Let me double check on a larger timescale right now.

roberthartung · 2020-07-08T07:21:18Z

Over a timeframe of 100seconds, I don't see any saw toothing. 4.63mA.

PeterKietzmann · 2020-07-08T07:32:50Z

Do you have a nucleo-f103rb available? Otherwise, the issue is quite old and someone should check on iotlab if we still face that problem.

roberthartung · 2020-07-08T07:47:02Z

@PeterKietzmann Unfortunately not. Let's wait until someone verifies that this problem actually still exists.

miri64 · 2020-07-08T07:55:14Z

I'll give it a look on IoT-LAB.

PeterKietzmann · 2020-07-08T07:56:15Z

I'm already at it. Seems to be still there. Will send plots in a moment

miri64 · 2020-07-08T07:57:03Z

Thanks @PeterKietzmann! Might also be a good idea to check the results with a proper Osci, if you have the hardware for it.

PeterKietzmann · 2020-07-08T08:05:53Z

With examples/hello-world on ad28752, FIT IoT-LAB grenoble node m3-101, power profiler settings with period of 140us and averae 4 samples.

PeterKietzmann · 2020-07-08T08:08:11Z

Theoretically I should have the hardware available. Don't know if I can make it today, though.

One other thing: There used to be s powering option for M3 nodes either from a battery or USB. I cannot find that option anymore, did they get rid of that?

roberthartung · 2020-07-08T08:08:37Z

This looks like a strange effect from some other hardware, not RIOT itself.

miri64 · 2020-07-08T08:17:27Z

One other thing: There used to be s powering option for M3 nodes either from a battery or USB. I cannot find that option anymore, did they get rid of that?

I don't remember that being a thing. Maybe @aabadie can help to answer that?

miri64 · 2020-07-08T08:18:49Z

This looks like a strange effect from some other hardware, not RIOT itself.

There is reason to believe it might be a RIOT issue:

I have seen this same sawtooth in RIOT on Mulle with local measurements as well so it's also not limited to the iotlab-m3 boards. I get a more or less horizontal line idling in Contiki.

PeterKietzmann · 2020-07-08T08:18:57Z

I agree that it looks like it, however, @gebart faced similar issues locally with a Mulle board (see comment) with RIOT but not contiki and I could not reproduce the issue with a different RIOT image (see mailing list). @kYc0o pointed out, that it might relate to a noisy environment (see comment). Although the period is too deterministic for noise, it might relate to some transceiver current drain due to inappropriate "uninitialization"? Needs further investigation that I cannot provide right now. But anyone with iot-lab access should be able to.

roberthartung · 2020-07-08T08:21:22Z

@miri64 yes, true. I've read the comment as well. My problem here is that components of the MCU and sensors will probably have a very fixed set of modes and therefore saw-toothing is quite hard. Saw-Toothing often comes from some analogue hardware or other stuff that happends over time. I just can't imagine of some piece of software that is responsible for this kind of smooth saw-tooth pattern.

miri64 · 2020-07-08T08:23:26Z

I just can't imagine of some piece of software that is responsible for this kind of smooth saw-tooth pattern.

No, that wasn't what I was saying either. Rather I agree with @PeterKietzmann that it might be some "uninitialization" issue. Some analogue pin or antenna that is hanging open in RIOT but not in Contiki, for some reason.

roberthartung · 2020-07-08T08:24:24Z

I just can't imagine of some piece of software that is responsible for this kind of smooth saw-tooth pattern.

No, that wasn't what I was saying either. Rather I agree with @PeterKietzmann that it might be some "uninitialization" issue. Some analogue pin or antenna that is hanging open in RIOT but not in Contiki, for some reason.

Yes, absolutely true. Totally looks like this kind of issue.

roberthartung · 2020-07-08T08:34:22Z

I just can't imagine of some piece of software that is responsible for this kind of smooth saw-tooth pattern.

No, that wasn't what I was saying either. Rather I agree with @PeterKietzmann that it might be some "uninitialization" issue. Some analogue pin or antenna that is hanging open in RIOT but not in Contiki, for some reason.

Yes, absolutely true. Totally looks like this kind of issue.

There is a battery connector on the board. Maybe the battery is responsible for some side effects.

PeterKietzmann · 2020-07-08T09:34:41Z

Looking at this schematic (sect. 3.2) and this schematic (sect. 3.11) it is not clear to me how to set up the same power supply conditions as on the testbed, and where to put my probes to measure the same point as the INA226 of the control node. @aabadie can you help out?

aabadie · 2020-07-08T11:51:17Z

I cannot find that option anymore, did they get rid of that?

Battery options were removed 5 years ago because the batteries had physical issues (and could explode).

It would help is someone could flash an hello_world application from Contiki or OpenLAB (FreeRTOS) and see if there's a difference. This way we could have a better idea where the problem comes from (RIOT or IoT-LAB).

PeterKietzmann · 2020-07-08T16:04:10Z

@aabadie thanks for the information, I didn't know about the exploding batteries. As reported in this comment there are a couple of indications pointing to RIOT. However, I'd like to reproduce the measurement locally with a multimeter. Can you tell how to set up the same power supply conditions as on the testbed and where to attach my probes to measure the same point as the INA226 of the control node?

aabadie · 2020-07-08T16:12:35Z

Can you tell how to set up the same power supply conditions as on the testbed and where to attach my probes to measure the same point as the INA226 of the control node?

All pins are router to the gateway via the specific connector which beside the usb port. I think it's quite difficult to directly access the hardware this way (unless you have a compatible connector). I think the FTDI chip is not taken into account when measuring power with the INA226.

miri64 added the Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors) label Mar 9, 2016

miri64 assigned kaspar030 Mar 9, 2016

miri64 added this to the Release 2016.10 milestone Oct 18, 2016

miri64 modified the milestones: Release 2016.10, Release 2017.01 Nov 11, 2016

PeterKietzmann modified the milestones: Release 2017.01, Release 2017.04 Jan 26, 2017

miri64 added this to the Release 2020.07 milestone Jun 30, 2020

miri64 modified the milestones: Release 2020.07, Release 2020.10 Jul 24, 2020

aabadie added Area: pm Area: (Low) power management Area: cpu Area: CPU/MCU ports labels May 20, 2021

MrKevinWeiss modified the milestones: Release 2020.10, Release 2021.07 Jun 22, 2021

MrKevinWeiss removed this from the Release 2021.07 milestone Jul 15, 2021

RIOT is saw-toothing in energy consumption (even when idling) #5009

RIOT is saw-toothing in energy consumption (even when idling) #5009

Comments

miri64 commented Mar 9, 2016

jnohlgard commented Mar 9, 2016

emmanuelsearch commented Mar 9, 2016

jnohlgard commented Mar 9, 2016

miri64 commented Mar 9, 2016

miri64 commented Mar 9, 2016

LudwigKnuepfer commented Mar 9, 2016

jnohlgard commented Mar 9, 2016

jnohlgard commented Mar 9, 2016

miri64 commented Mar 9, 2016

miri64 commented Mar 9, 2016

malosek commented Mar 10, 2016

miri64 commented Mar 10, 2016

malosek commented Mar 10, 2016

miri64 commented Mar 10, 2016

jnohlgard commented Mar 11, 2016

jnohlgard commented Mar 11, 2016

malosek commented Mar 14, 2016

roberthartung commented Jun 30, 2020

roberthartung commented Jul 8, 2020 • edited Loading

roberthartung commented Jul 8, 2020

PeterKietzmann commented Jul 8, 2020

roberthartung commented Jul 8, 2020

miri64 commented Jul 8, 2020

PeterKietzmann commented Jul 8, 2020

miri64 commented Jul 8, 2020

PeterKietzmann commented Jul 8, 2020

PeterKietzmann commented Jul 8, 2020

roberthartung commented Jul 8, 2020

miri64 commented Jul 8, 2020

miri64 commented Jul 8, 2020

PeterKietzmann commented Jul 8, 2020

roberthartung commented Jul 8, 2020

miri64 commented Jul 8, 2020 • edited Loading

roberthartung commented Jul 8, 2020

roberthartung commented Jul 8, 2020

PeterKietzmann commented Jul 8, 2020

aabadie commented Jul 8, 2020 • edited Loading

PeterKietzmann commented Jul 8, 2020

aabadie commented Jul 8, 2020

roberthartung commented Jul 8, 2020 •

edited

Loading

miri64 commented Jul 8, 2020 •

edited

Loading

aabadie commented Jul 8, 2020 •

edited

Loading