ruuvi/ruuvi.firmware.c

Ruuvi Firmware version 3. Built on top of Nordic SDK 15, uses both Ruuvi and external repositories as submodules. In Beta, no breaking changes are intended but may be done if absolutely necessary

ruuvi.firmware.c

Current git repository status:

Ruuvi Firmware version 3. Built on top of Nordic SDK 15, uses both Ruuvi and external repositories as submodules. Under development, please follow Ruuvi Blog for details. The project is in beta stage, no breaking changes are expected

Setting up

Prerequisites

• gcc-arm-none-eabi-7-2018-q2-update Check that nRF5_SDK_15.3.0_59ac345/components/toolchain/gcc Makefile.posix or Makefile.windows points to it.
• git
• python 3.7 or later and pip package manager
• Nordic mergehex merge 2 or 3 (not 4) .hex files into one.
• Nordic nrfutil Creates DeviceFirmwareUpdate zip file from hex
• Nordic Command Line Tools
• Nordic nRFconnect for your desktop or phone to upload DFU to the Ruuvi and a means to transfer the DFU zip file to you phone.
• A computer or phone with a bluetooth radio to receive advertisments from the ruuvi. See Dealing with the data
• On Mac OS XCode

Suggested

• Ruuvi Dev kit board and a USB power & data cable.
• Or any other SWD programmer and a cable matching your target board.

To validate you changes, for example before making Pull Requests

• Ceedling
• PVS-Studio Analyzer
• Artistic Style
• doxygen

SDK 15.3.

Download Nordic SDK15.3 (.8GB)and install it at the project root. If you're working on multiple nRF projects, use symbolic linking to have only one copy.

Creating your fork

Use git to include all Submodules ( ruuvi.drivers.c, ruuvi.endpoint.c, etc )

Run git submodule sync --recursive and git submodule update --init --recursive to update the modules from the master repository .

Coding style

Use coding style consistant with BARR-C:2018. Coding style is enforced with Artistic Style. Some source files were inserted into the master repository before this was established and running astyle will revise the source as necessary. See .astylerc for non-default options (for example max-code-length=90). Run make astyle.

Compiling and Testing

Segger Embedded Studio should be used for developing.

Segger Embedded Studio is set up by installing nRF Connect for Desktop and following Getting Started instructions.

Start SES

File -> Open Solution -> ruuvi.firmware.c.emProject. Each of the target boards is in their own project. Sess 'build' compiles and links the firmware. In the Project Explorer select the correct project according to the appropriate tag name. Select the Build Configuration: Debug, Long Life or Release.

Build

Navigate to Build -> Build <project name> or press the F7 key.

Connect you board with either:

• nRF52 DevKit and RuuviTag Development Shield.
• nRF52 DevKit and TC2030-CTX-NL 6-pin Cable

Debug

Navigate to Debug -> Go or press the F5 key. This will flash the firmware and start the debugger.

ARMGCC is used for Jenkins builds

You can make the project and a single variant by runnning "make variantName" (for example "make ruuvitag_b" at top level of this repository

When building binaries for distribution, use the provided 'Makefile' script. This way you can be certain to have a repeatable build process. The Makefile uses the tag name of current git commit for filenames and version number. Tags should be valid semantic versions, starting with v and possibly having pre-release information such as -rc2. Do not add build information such as +TestFW. If you have tagged the version as v3.99.1 the files will be named $BOARD_armgcc_ruuvifw_$VARIANT_v3.99.1_$TYPE.extension. For example ruuvitag_b_armgcc_ruuvifw_default_v3.29.3-rc1_full.hex.

Flashing

Connect your board with either:

• nRF52 DevKit and RuuviTag Development Shield.
• nRF52 DevKit and TC2030-CTX-NL 6-pin Cable

nRF Command Line Tools

Navigate to ruuvi.firmware.c/src/targets/<board name>/armgcc.
Run make to compile the application.
Run ./package.sh to generate the complete firmware HEX and ZIP files.
To flash the tag, run

nrfjprog  --eraseall   # including previous bootloader
nrfjprog  --program ruuvitag_b_armgcc_ruuvifw_v3.30.0-RC5_app.hex --verify --fast --reset 

Finishing up

Static analysis

The code can be checked with PVS Studio and Sonarcloud for some common errors, style issues and potential problems. Here is a link to generated report.

PVS

Obtain license and software from Viva64. Installation process is described in ruuvi.docs.com Make runs PVS Studio scan and outputs results under doxygen/html/fullhtml. This produces many warnings, you need to filter the warnings you're interested in. For example you probably want to filter out warnings related to 64-bit systems.

Sonar scan

Travis pushes the results to SonarCloud.IO. SonarCloud uses access token which is private to Ruuvi. You need to fork the project and setup the SonarCloud under your own account to run Sonar Scan on your own code.

Running unit tests

Ceedling

Unit tests are implemented with Ceedling. Run the tests with ceedling test:all

Gcov

Ceedling can also generate Gcov reports with ceedling gcov:all utils:gcov. The report can be found under build/artifacts/gcov.

Unit test continuous integration

Travis will fail the build if unit test fails and Gcov results will get pushed to SonarCloud.

How to contribute

Please let us know your thoughts on the direction and structure of the project. Does the project help you to understand how to build code for the RuuviTag? Is the structure of the project sensible to you?

If you want to assist in the project maintenance by fixing some issues doxygen.error is a good place to look for code which needs better commenting. Project badges at the top of the readme point to issues which range from trivial clarifications to complex refactoring.

If you want to add new features, please discuss the feature first at the Forum and then create ceedling unit tests for the functionality. Once the functionality is agreed and testable in can be integrated into project.

Licensing

Ruuvi code is BSD-3 licensed. Submodules and external dependencies have their own licenses, which are BSD-compatible.

Documentation

Document is generated with Doxygen. Run make doxygen to generate the docs locally, or browse to Travis built docs

ruuvi.firmware.c's Issues

v3.29.0-RC2 LED: Leds should indicate self-test status

Currently all legs are activated and deactivated regardless of self-test status.
Change led actions at boot to activate red led while self-test is in progress and turn green led on if no errors were detected.

3.28.12: Excess current consumption while GATT is connected

Consumes approximately 330 uA during GATT connection due to fast connection intervals. Reduce the connection interval and use connection event extension for data bursts.

3.28.0: First advertisement packet after GATT disconnection has 0 in measurement sequence

3.28.12: ARMGCC build: Leds do not blink

initialization: order of inits: BLE first

Although it seems that LEDs are easy and cannot reasonably fail,
It would be much better to initialize BLE and start advertising earliest.
Does BLE depend on TIMER? RTC?
Consider that BLE has no external GPIO solder connections.

GPIO, IC2 and SPI should be initialized LAST.

Is there any real-world data regarding failures?
From production final tests?

3.28.8: Firmware crashes on 811 ICs on flash reads

Feature: Allow configuring settings via GATT connection only for a certain time after boot

Make it not possible to configure settings wirelessly after a hard-coded time window has closed. After the window has closed, it is possible to reopen the window by applying an NFC field.

Feature: Radio configuration over GATT

e.g. data format, transmission interval, PHYs used, channels used.

LIS2DH12: Initialization failure on first boot

Sometimes on first boot LIS2DH12 returns a test failure.

{
"firmware":"Ruuvi FW-debug",
"board":"RUUVITAG_B",
"ruuvi.boards.c":"0.7.0",
"ruuvi.drivers.c":"0.2.5",
"ruuvi.libraries.c":"0.2.0",
"libraries": {
"peak2peak":{
"valid_data":"pass",
"nan_data":"pass",
"overflow_fpu_errors":"FPU OFC Error",
"overflow_data":"pass",
"input_validation":"pass"
},
"rms":{
"valid_data":"pass",
"nan_data":"pass",
"overflow_fpu_errors":"FPU OFC ErrorFPU OFC Error",
"overflow_data":"pass",
"input_validation":"pass"
},
"variance":{
"valid_data":"pass",
"nan_data":"pass",
"overflow_fpu_errors":"FPU OFC ErrorFPU OFC Error",
"overflow_data":"pass",
"input_validation":"pass"
},
"ringbuffer":{
"put_get":"pass",
"overflow":"pass",
"overdrain":"pass"
},
"liblzf":{
"compress_decompress":"pass",
"decompress_twice":"pass",
"compress_ratio:""0.54%",
"compress_ratio_test":"pass",
"invalid_input":"pass"
},
"total_tests":"19",
"passed_tests":"19"
},
"drivers": {
"flash":{
"init":"pass",
"uninit":"pass",
"store":"pass",
"load":"pass",
"free":"pass",
"gc":"pass"
},
"power":{
"dcdc_internal":"pass"
},
"timer":{
"init":"pass",
"create":"pass",
"single_shot":"pass",
"repeat":"pass"
},
"scheduler":{
"init":"pass",
"execute":"pass",
"put":"pass"
},
"sensors": {
"SHTCX": {
"init":"pass",
"modes":"pass",
"configuration":"pass",
"interrupts":"skipped"
"data":{
"timestamp_ms": "4225",
"humidity_rh": "41.95",
"temperature_c": "24.81",
}
},
"BME280": {
"init":"pass",
"modes":"pass",
"configuration":"pass",
"interrupts":"skipped"
"data":{
"timestamp_ms": "4448",
"humidity_rh": "39.27",
"pressure_pa": "100923.18",
"temperature_c": "24.61",
}
},
"LIS2DH12": {
"init":"fail",
"modes":"fail",
"configuration":"fail",
"interrupts":"skipped"
}
},
"radio":{
"init":"pass,"
"address_set_get":"pass"
},
"ble_adv_1_mbit":{
"init":"pass",
"interval":"pass",
"extended":"pass",
"power":"pass",
"scan":"pass"
},
"ble_adv_2_mbit":{
"init":"pass",
"interval":"pass",
"extended":"pass",
"power":"pass",
"scan":"pass"
},
"ble_gatt_1_mbit":{
"init":"pass",
"tx":"timeout"
"throughput":"0.000 bps"
},
"ble_gatt_2_mbit":{
"init":"pass",
"tx":"timeout"
"throughput":"0.000 bps"
},
"uart":{
"init":"pass",
"tx_rx":"pass"
"rx_corrupt":"pass"
"rx_short":"pass"
},
"gpio":{
"init":"pass",
"configure":"pass",
"toggle":"pass"
},
"gpio_interrupt":{
"init":"pass",
"enable":"pass"
},
"gpio_pwm":{
"init":"pass",
"start":"pass"
},
"nfc":{
"init":"pass",
"tx_rx":"timeout"
},
}
}

This is probably related to #65. In some cases, such as when board is moved on boot, the selftest would fail as the LIS2DH12 selftest verifies change of sensor values against self-test excitation. The app_sensor.c works around the issue by retrying the initialization, but the root cause of initialization failures should be found and fixed.

Error check: Log source of fatal error. Print fatal errors via RTT on debug versions.

task_communication: Reply not sent if the TX buffer is full

The incoming data handler does not check the error code, this can cause replies being dropped. Check if the error code is RUUVI_ERROR_NO_MEM and retry sending reply.

Feature: Sensor alert limits configured over GATT

3.28.10: Battery voltage measurement not done

The callback to measure battery voltage after radio activity is not implemented.

3.28.x: Heartbeat transmissions accumulate during log read over GATT

Add support for Nordic SDK 17.2

versioning lost major.minor.update

NFC SW now reports 7 characters from GitHub.

Automatic versioning (only) by a tool looses the intelligence behind "This is a version".

I would like to suggest that SW "version" be returned to the traditional 3 numeric field format of major.minor.update.

Perhaps an additional field can be defined containing the GitHub ID ( and a date-time too!)

3.28.x NFC data field contains garbage

Feature: Combine data from different sensors

Currently (3.28.13) firmware only selects first available sensor, go through all sensor backends and fetch data as required to fill all the fields.

For example temperature + humidity from SHTC and air pressure from BME

3.27.x: Movement counter non-functional

Acceleration logging

The acceleration related events aren't logged right now, add them to log

Kalervo: ARMGCC builds fail to boot

Red led blinks quickly / irregularly.

Feature: Temperature,.. (env sensors )logging

Needeed:
Env sensors logging in a circular array every x minutes (configurable) and when mobile app connecto to tag get all logs.
if no smartphone connect and circular array go to end they back to init and replace the older by new.

v3.29.0-RC2: DFU is possible without physical contact.

Currently DFU service is always open. For security reasons, physical contact should be required before updating device.

tests: Move driver tests under ruuvi.drivers.c

Every project can benefit from testing the drivers as they're used in project, and driver-specific tests should be under drivers. Refactor.

static bool m_is_init; should be initialized

in src/tasks/communication/task_advertisement.c

Should
static bool m_is_init;
be
static bool m_is_init = false;
?

Where is the Gatt code?

Hi
I am trying to learn with this code
I have already flash hex into ruuvi and it works but I can not find where characteristics and services were declared.

Thanks

Alex

Downgrade back to 2.5.9

How would one do this?

Continuous integration: Run static analysis

Find a suitable tool to run static code analysis and raise any issues.

Error in ruuviblog-branch

Branch ruuviblog has an error in ./targets/ruuvitag_b/armgcc/package.sh line 18:
wget $BOOTLOADER
Shouldn't it be
wget https://github.com/ruuvi/ruuvi.nrf5_sdk15_bootloader.c/releases/download/3.0.0/ $BOOTLOADER

Refactor tasks into submodule

Split functionality common to any firmware using Ruuvi drivers to their separate repository to allow working on common functionality across many projects using git workflow

Improve toolchain setup instructions

initialization: init all subsystems before checking for failure

Previously, Version 2 initialized all subsystems and set a unique flag for any subsystem that failed. After all initializations were attempted the cumulative result was evaluated.
This permits a tag to continue to operate even if one subsystem cannot be initialized or causes a hangup.
The only peripheral subsystem that must be successfully initialized and operational is BLE (and a RTC which It depends on) since if the tag is being used as a proximity beacon, sensors are not necessary. Additionally failure of the accelerator to initialize may not be important in a "old-chain" application.

v3.29.0-RC2: Advertisement at boot-up is too slow.

The tag should advertise at 100ms interval at boot for 5 seconds to speed up discovery after boot. Currently advertisements are at 1285 ms interval.

Logging measurements in advertise format would allow for storing much more data

in /app_log.h
Would it be better to keep measurements in app_log_element_t in integer hundredths rather than float?
I wonder if there are sever compression considerations especially dealing with successive readings that are not represented well in hexadecimal fractions which are actually nearly the same.

Consider the value 0.10 which in floating point results in 0x3dcccccd. YUCK while in integer hundredths is simply 0x00...0A

Try using https://www.h-schmidt.net/FloatConverter/IEEE754.html on other simple measurements.

That is also more consistent with the transmission format.

Refactor: GPIO to be plain uint16 instead of union

Using unions for GPIOs causes unnecessary complexity and bugs, such as #54 . Refactor drivers to use plain UINT16, and then update firmware.

Feature: Support TMP117, NTC thermistor, photodiode

ruuvi.drivers.c: Inconsistensies in naming platform <-> interface

Some interface functions, such as delay and RTC functions are named as platform functions. Refactor.

Bug: new data received while logs are transmitted cause error

Handle too quickly incoming data gracefully

initialization: order of inits: WDOG init before anything

The WDOG timer must be initialized first, even with a rather large value. This can prevent initialization code from hanging without any indication that anything has gone wrong.

Cannot open the SeS

when im try to open the ses file it say crash . im using Seeger Embedded Studio for ARM v4.12

Sample battery voltage at interval

Current battery voltage sampling gets triggered on every radio transmission, which is unnecessarily often.
A logic to update the voltage only once per minute, with interval configurable in application_mode_default.h should be added.
Related to #86

/** @brief Resample battery voltage at this interval */
#ifndef APP_BATTERY_SAMPLE_MS
#   define APP_BATTERY__SAMPLEL_MS (60U*1000U)
#endif

missing application_bluetooth_config.h

Feature: Acceleration logging

Wiki needs to be initialized ?

I attempted to add content to the wifi but it seems to need to be setup or initialized .

Battery measurement works only on first sample(s)

Battery measurement is synchronized to radio, ADC is configured for sampling on before_radio_activity event and actual sample is taken on after_radio_activity event. The sampled data is stored in rt_adc and read later in app_heartbeat when sending data as BLE advertisement.

The ADC was uninitialized in 3.28 firmwares after sample to reduce power consumption. Now either uninitialization or reinitialization errors and the data won't be updated.

app_sensor.c:236 WARNING: INVALID_STATE
app_sensor.c:231 WARNING: BUSY
app_sensor.c:236 WARNING: INVALID_STATE
app_sensor.c:231 WARNING: BUSY

Relevant functions are in app_sensor, app_heartbeat and ruuvi_task_adc.

The sampling after radio transmission should be fixed. Ruuvi Station app can be used to check that ADC data is getting updated.

ruuvi_interface_lis2dh12.c:175 FATAL: SELFTEST

I've faced the problem with 2 of my RuuviTags - in connected state they were restarting with the

ruuvi_interface_lis2dh12.c:175 FATAL: SELFTEST

error. Re-programming didn't help. Next morning the issue was "fixed". Without any action from my side.

The tag advertised ok, but didn't heartbeat.

Initialization: Actions on failure: save status, BLE, log, LED and spin before boot

When the initialization determines that a fatal failure has occurred there is a series of actions that must be taken.

0. The watchdog must be loaded with a very large value to prevent triggering.

1. Status saving: Hardware never fixes itself. A battery nearing exhaustion may cause unexpected events to occur or other temporary external conditions may cause a failure. Once a subsystem fails initialization a permanent status must be saved. It must persist across resets and be easily locatable. Placing it in the UICR area satisfies these requirements. As other Configuration Information settings may be present, a good place is UICR[31], that is the last location. This status can be examined by the system which can avoid using the failing subsystem or by a user with a debugger like J-Link, Ozone or nRFproj. A future enhancement would be to include this in the NFC utility which manages the settings.

2. BLE Message: The next action is to transmit, via BLE, a non-sensor data packet. This must include the version, configuration information and the status. This allows any data collection system to observe the failure, record it and take action on the failure. This is the only way that the problem can be observed without knowing in advance that a failure has occurred which the following listed actions require. A portion of the fault flag should contain a counter containing the number of messages sent. When a threshold is reached messages will no longer be sent. This prevents flooding the collection system. It would be beneficial if the system reduced this counter after returning to successful operation for several minutes.

3. NFC message may be helpful in diagnosing the problem but will only be observed if a receiver is enabled and in range. This also requires an application that is capable of receiving and displaying the message.

4. Log message will assist in diagnosing the problem but, as with NFC message, it is only helpful once it is known that there is a problem since there must be a log device attached (and of course logging must be enabled at compile time).

5. The LED must be blinked in a manner that is easily recognizable as a failure in the initialization and not some other failure or the entry into the boot loader. A series of 13 blinks to indicate the unlucky event followed by a pause and then the flag. Again, this is only useful if it is known that there is a failure as it requires the cover to be removed and an observer present.

6. A local CPU based interrupt disabled, delay spin, not dependent on the RTC must be executed. This must be very long, perhaps even minutes, to permit possible interaction with a connected debugger. Continuing too soon will only cause rapid, undesirable looping. As the tag has already been deemed to be in failure mode, resuming operation is not urgent.

7. Finally a software initiated reset will invoke the boot loader and cause application initialization to set the static variables to zero!

Perhaps a condition that invoked initialization no longer exists and the system can resume operation.

Refactor: Move NFC from peripherals to communication

Continuous integration: Setup automatic lint

Enforce consistent styling (tabs vs spaces, number of spaces in indentation etc).

Feature: Keep sending data broadcasts during GATT connection

The tag stops advertising during GATT connection. This makes tags single-user if there's iOS user in household. As a fix, resume data advertising in non-connectable state during GATT connections.