nordicsemiconductor / nordic-thingy52-fw

Nordic Thingy:52 software development kit. This kit is designed to assist users in developing their own custom firmware for Thingy. Please see http://www.nordicsemi.com/thingy for the latest news and software releases.

DEPRECATED

This repository is deprecated and will be archived. No further development activities are planned.

For enquiries regarding Thingy:52 please create a ticket at devzone.nordicsemi.com

Nordic Thingy:52 SDK

Welcome to the Nordic Thingy:52 software development kit. This kit is designed to assist users in developing their own custom firmware for Thingy. Please see http://www.nordicsemi.com/thingy for the latest news and software releases.

Consult the firmware documentation for more details.

Prerequisites

Before running the scripts below, make sure you have the following software installed:

1. Git v2.xx.xx, Available from https://git-scm.com/. Use default configurations.
2. Install GNU ARM embedded toolchain v4.9-2015q3. Available from https://launchpad.net/gcc-arm-embedded/4.9/4.9-2015-q3-update. Use default configurations.
3. Make must be installed and be in system path. For example http://gnuwin32.sourceforge.net/packages/make.htm.
4. Create a user at https://www.invensense.com/. Under "Downloads" download "Embedded MotionDriver 6.12". Unzip the downloaded motion_driver_6.12 folder and navigate to motion_driver_6.12/mpl libraries/arm/Keil. Unzip the folder libmpllib_Keil_M4FP.zip. Copy the extracted library libmpllib.lib into <your Thingy folder>/libs/libmpllib_Keil_M4FP/. Finally, unzip /motion_driver_6.12/mpl libraries/arm/gcc4.9.3/liblibmplmpu_m4_hardfp.zip and copy the extracted library liblibmplmpu.a into the folder <your Thingy folder>/libs/liblibmplmpu_m4_hardfp/.

Bluetooth SoftDevice

Thingy FW version 2.0.0 is compatible with softdevice s132 v4.0.5

Setting up the SDK

Run setup_sdk.bat on Windows or setup_sdk.sh on Linux/Mac.

These scripts will download and compile the micro-ecc library and set up symbolic links.

Compiling the code

To compile the code, please consult the compiling new firmware page in the firmware documentation.

nordic-thingy52-fw's Issues

Issues in CCS811 sensor reading

The following are the issues we are having with the ccs811 sensor.

If we are moving a sensor from places where there is a high level of gas to a low level of gas. The sensor is taking a large amount of time to settle down to the actual gas level of that place.

We have noticed that sometimes there are sudden jumps in CO2 and TVOC values.

If sensors exposed to the high level of Co2 and TVOC ( Co2: 2000 to 2500 TVOC: 400 to 800) constantly for more than 4 to 5 weeks they are getting damaged after that those sensors are reporting co2 value of nearly around 400 to 500 even if it is exposed to the higher level of gas.

Following is the initialization flow of the Gas sensor

Turn on the sensor.
Initialize sensor in PulseHeat drive mode (10-second interrupt).
Update temperature and humidity at every 2-second interval.
After a reset or a startup Wait for 30 min for the gas sensor to adjust according to the environment and then write the previously-stored baseline value if present else stores the baseline.
Following Hardware we are using

Microcontroller : nRF52832.
Temperature and humidity sensor: HTS221.
Gas sensor: CCS811
Please let us know, what is going wrong in the initialization process of the sensor resulting in these issues

Below is the flow chart for the reference

can compile and program with GCC on ubuntu 16.04, but the code doesn't run

Hi,
I use GCC to compile the code. And program the board with J-link on linux (ubuntu 16.04). But I didn't see the LED light on. And my phone cannot connect to it.

However, if I flash the precompiled HEX file (thingyv210HW10.hex) into the device, it works.

Here are the tools and commands I used to do it:
1, gcc-arm-none-eabi-8-2019-q3-update. I don't use gcc-arm-none-eabi-4_9-2015-q3, because the ubuntu 16.04 cannot recognize it.
2, nrfjprog --family nRF52 -e, to erase the device.
3, nrfjprog --family nRF52 --program _build/nrf52832_xxaa_s132.hex, to flash the device.
4, nrfjprog --family nRF52 -r, to run the code.

And nrf52832_xxaa_s132.hex is 380 bytes less than the precompiled HEX file (thingyv210HW10.hex).

Do I have to use gcc-arm-none-eabi-4_9-2015-q3 to compile the code? Or it could be some other issues?

armgcc uses wrong soft device version

pca20020_s132/armgcc/Makefile incorrectly references s312 version 2.0.0, which is not present in SDK 12.1.0. The Keil build infrastructure, as well as the official thingy_v1.1.0.HW_1.0.hex confirms that 3.0.0 is what's used.

CCS811 calibration problem with 2.x plus

There seems to be something wrong with the way the Thingy 2.1.0 firmware manages CCS811 calibration.

I've set up several Thingies next to each other in a interior space several meters from a forced air heating vent, connected to a central that receives temperature and humidity every 15 s and gas readings every 10 s and logs the readings to OpenTSDB. The image below covers about 19 hours and demonstrates that the TVOC readings are correlated with temperature with an implausibly high gain.

The data collection started about 16 hours prior to the data displayed in the image with three devices located in three different rooms spanning 8 m maximum distance with no doors blocking air exchange. All devices started at zero TVOC, then rose with slightly different slopes not obviously correlated with the differences in ambient temperature. (Several devices had been used for short periods with the Android app and I suspect the difference was due to previous gas sensor collections.)

The first couple hours in the image show waves in TVOC that rise at times when a forced-hot-air gas furnace was running, and fall when it was off. Use of the furnace explains variation in TVOC, but the magnitude of the reading differences is implausible.

Around 16:00 I moved two devices to location of the device with the lowest magnitude TVOC. This area was about 0.5 Cel warmer than the others which may partly explain the initial ramp-up; around 16:30 the set temperature of the furnace increased, providing an additional significant rise stabilizing around 17:00, after which temperature and magnitude TVOC remained steady for a couple hours.

Around 19:00 I added a fourth device with virtually no prior on-time, which required that the central be restarted. On reconnection all readings dropped to zero, then rose linearly at a rate proportional to their relative difference prior to restart, then at 30 minute jumped significantly. The newly added device, which had no significant prior run-time, read zero for most of this period.

The set temperature for the environment dropped about 5 Cel at 22:00, which is masked by a steady drop after the sudden jump up at 16:30, then rose again around 04:00, with pulses again correlating to furnace activity. During this period the newly-added device (shown in detail in the right column) showed large increases in TVOC gain as temperature.

While all readings are still within the nominal 48-hour burn-in, the trends are not good. The jump at 30 min after connection to a central, as well as the correlation of gain with temperatures, suggest something done by the firmware. The two devices with lowest readings had some burn-in time with firmware 1.1.0; the two with highest readings were delivered with firmware 2.0.0 and immediately updated to 2.1.0.

In short, the as-implemented behavior is horribly wrong. I'll keep this running for a while longer to see if it converges to consistency, but I'm not hopeful. I'm aware of issue #11 which might contribute to fixing this, but I suspect there's something wrong with the on-going maintenance of the BASELINE register as well as absence of specific calibration support. (Both notes on page 11 of the datasheet appear relevant.)

Makefile flash_softdevice target points to incorrect sd version

In the latest FW 2.1.0 update, it looks like the makefile reverted back to using SD 2.0.0 instead of 4.0.2.

Makefile diff
flash_softdevice:
@echo Flashing: s132_nrf52_2.0.0_softdevice.hex
- nrfjprog --program ../../../sdk_components/softdevice/s132/hex/s132_nrf52_4.0.2_softdevice.hex -f nrf52 --chiperase
+ nrfjprog --program ../../../sdk_components/softdevice/s132/hex/s132_nrf52_2.0.0_softdevice.hex -f nrf52 --chiperase
nrfjprog --reset -f nrf52

Also, the actual hex file for 4.0.2 (as well as 2.0.0) is missing from embedded SDK.

missing: external/sdk13/components/softdevice/s132/hex/s132_nrf52_4.0.2_softdevice.hex

CCS811 driver replicates error in vendor documentation.

This code appears to have the same bug reported at sparkfun/Qwiic_BME280_CCS811_Combo#8. Repeating the summary:

The code for configuring the CCS811 ENV_DATA values faithfully represents the instructions in the CCS811 Programming guide section 16, being:

i2c_buff[0] = ((RH % 1000) / 100) > 7 ? (RH/1000 + 1)<<1 : (RH/1000)<<1;
i2c_buff[1] = 0;
if(((RH % 1000) / 100) > 2 && (((RH % 1000) / 100) < 8)) {
  i2c_buff[0] |= 1;
}

The demonstration code is wrong, as it results in storing a value that is one unit too large when the fractional part is strictly between 0.7 and 0.8. In that case the whole value is incremented and the half-value is added, applying the half-round operation twice.

An appropriate replacement given the limited resolution of humidity data here is probably something like:

tx_buff[1] = (rh_ppth + 3) / 5;
tx_buff[3] = (250 + temp_mdeg) / 500;

to round the MSB of each to the nearest half-unit.

Does not work

Thingy disconnected after discovering serices

How to use the android app control expansion pin(Nordic Thingy:52)

I want to implement, how to change the state of these four Mosfets in UI service: "EXT pin characteristic" (0303) using Nordic-Thingy52-FW android project here

Setting adv_params.timeout to 0 causes error boot loop

On both the Android and iOS Thingy apps, if the Advertising Timeout is set to 0, and then the app disconnects, the Thingy goes in to a perpetual error boot loop with the red LED.

The only way that I have found to fix this is erase and reflash thingy_v1.1.0.HW_1.0.hex. This erases the settings loaded into m_ble_config. I don't believe there is any other way to force the Thingy to load the factory defaults from m_ble_default_config.

I was able to power on with the button pressed to force into the bootloader. Performing a DFU update of the v1.1.0 does work, but doesn't erase the settings in flash. After the DFU completes, it is still in the red LED boot loop.

The problem might be that in Limited Discoverable mode advertising, BLE_GAP_ADV_TIMEOUT_LIMITED_MAX = 180, and I don't think you can use a value of 0. This is allowed in General Discoverable mode by using BLE_GAP_ADV_TIMEOUT_GENERAL_UNLIMITED = 0. I'll have to debug it more, but I think a simple bounds check on adv_params.timeout will prevent this.

Linux install: incorrect installation instructions for armgcc invensense library

For gcc users README.md instructs:

Finally, unzip \motion_driver_6.12\mpl libraries\arm\gcc4.9.3\liblibmplmpu_m4_hardfp.zip and copy the newly created folder liblibmplmpu_m4_hardfp to <your Thingy folder>/libs.

This is incorrect: the supplied liblibmplmpu_m4_hardfp.zip doesn't wrap the library in a directory (folder) (at least not with the version I downloaded this morning). The commands that worked for me are:

cd /path/to/Nordic-Thingy52-FW
cd libs
unzip '/tmp/motion_driver_6.12/mpl libraries/arm/gcc4.9.3/liblibmplmpu_m4_hardfp.zip'
mkdir liblibmplmpu_m4_hardfp
mv liblibmplmpu.a liblibmplmpu_m4_hardfp

Calibration Mode For Nordic Thingy

An issue has been raised here:
NordicSemiconductor/Android-Nordic-Thingy#3

rt_sys.h missing when imported to Segger

When imported to Segger Embedded Studio, the project fails to compile with the error
rt_sys.h: No such file or directory

It is called in RTT_Syscalls_KEIL.c

Please update doc site with v2.1.0

Hi @jorgenmk , I see that you did some commits related to doc updates - but the site still shows 2.0.0:
https://nordicsemiconductor.github.io/Nordic-Thingy52-FW/documentation/index.html

Maybe a simple deployment step needed?

DFU/bootloader support?

The documentation suggests we should be able to install our own boot loaders to support modified firmware. That page is somewhat lacking in detail; more importantly there doesn't appear to be any bootloader source for pca20020.

There is something in the thingy project/bootloader_secure directory but it's for a different board and possibly a different SDK version.

nrf_dfu_mbr_init_sd reboots

I got permanent device reboot due hardware exception when come to this call:

Nordic-Thingy52-FW/external/sdk13/components/libraries/bootloader/nrf_bootloader_app_start.c

Line 57 in 99be6c1

err_code = nrf_dfu_mbr_init_sd();

The exception is because of bad memory access in SD132 v4.0.2 in function at address 00028720 - as it is closed source hex file cannot investigate further.

I tried to update SD132 to latest version 7.0.0 to check if it will work but the API differ too much and I give up at the end.

Could someone suggest me what I could do to avoid the bad memory access and the following reboot?

Thingy hardware revision 1.0.0 support

I am having this new hardware but the keil projects atleast do not have this version in the dropdown menu. When compiling it with 0.9.0 settings and flashing into 1.0.0 hardware, i have asserts as the sensor hardware id verification fails. Can you please add support for it?

Bootloader fails to compile under ARM GCC

1. Missing makefile configuration

It looks like bootloader files are patched to reference reference "pca20020.h" board definition but makefile for bootloader is not updated with required paths and additional source files.

Makefile: project/bootloader_secure/pca10040/armgcc/Makefile

2. Missing micro-ecc build for armgcc

micro-ecc build for armgcc is missing.

Error in Environment Service - Temperature

ble_tes_temperature_t cannot correctly represent temperatures below zero but above -1 !

See:

https://devzone.nordicsemi.com/f/nordic-q-a/47223/error-in-thingy-52-environment-service---temperature

Segger Project File Missing

In the project, there are no Segger Project Files.

I'm trying to use Segger Studio to run, I've also tried importing the Kiel project, but I am encountering a lot of errors.

Is it possible to add a segger project so we can modify the code easily?

Logs

Hi,

I have a Sparkfun nrf52832 connected to a J-link Ultra+. I can build and flash the bootloader, softdevice and firmware. Before building the firmware I changed the following macro:

NRF_LOG_ENABLED 1

No errors, I use the JLinkRTTClient to see the logs but in this case there are no logs. I've been trying to make this work for a while now. How can I see the logs?

Gabriel

EDIT: I'm using OSX
EDIT2: I downloaded the hex file and flashed it using nrfjprog on both the Sparkfun nrf52832 or the Rigado nRF52 DK and I can't see the ble device or any logs.

It doesn't run without connect j-link viewer

Good evening,

I'm having some difficulties with the thingy52. I used it as the basis of development for the project and up to this point without major problems. However, my code runs only have an active connection without j-link. If I disable j-link and reset nrf52, the system just hangs. Anyone would know informs what happens and how to correct?

Will not build in SES

The thingy 52 firmware does not build in SES

Also see this thread here on Nordic Devzone

https://devzone.nordicsemi.com/f/nordic-q-a/51236/unable-to-compile-ses-project-in-thingy-52-sdk

Makefile - Make -j is not working on rebuild

Enable debug

Hello guys.

I'm new with nodic nRF52 SDK and I tried to enable debug by setting 1 on "NRF_LOG_ENABLED" in sdk_config.h, but nothing happens in com port criated by Jtag (pca10040).

Where is my error? What is the correctly procedure?

SOLVED: Thingy fails to enter sleep on BLE adv timeout

Upon BLE adv timeout, thingy_ble_evt_handler in main.c calls sleep_mode_enter function. This function in turn will call:

err_code = sd_power_system_off();

The problem is that this will return without putting device into sleep. This is without debugger attached to the device.

Repro steps:

• Get FW 2.0.0 from git.
• To speed up adv timeout, change thingy_config.h APP_ADV_TIMEOUT_IN_SECONDS from 120 to 15
• Flash SD and FW.
• Detach debugger.
• Reset device.
• Upon boot, thingy will enter adv mode with LED set to breathe mode.
• Wait 15 or more seconds.

Expected:

• Device will enter sleep mode, LED will be off, and device will not be discoverable over bluebooth.

Actual:

• Notice that LED will keep blinking blue (as per UI_CONFIG_DEFAULT_DISCONNECTED setting).
• Device is discoverable over bluetooth.

mpl libraries not included when imported to SES

I imported the KEIL project to Segger Embedded Studio and I was able to compile without errors. However, when I build the code, the IDE is not able to find the mpl libraries like accel_auto_cal.c, compass_vec_cal.c etc which are supposed to be in the libmplmpu.lib. How do I solve this error?

windows keil Compile libmpllib.lib could not find it

Please help,thanks

Rebuild with Keil does not work

After a failing to get importing and rebuilding under SES I tried to fall back to Keil.
Unfortunately this does not appear to work ether!
It looks like it tries to pull in some obsolete packs which according to the error message are no longer available.
I am using uVersion5 on Windows 10

3D Motion Problem in a Specified Movement

Hello,

It seems to me that there is an issue about the usage of MPU-9250.

I motioned Thingy and I observed its movement on the app. In all movement combination, SDK finds Thingy' s location perfectly (I can see it on the app) except one movement.

Now, I am trying to explain this problematic movement.

I put the Thingy (on its bigger surface) on a table in the way that for example "Nordic Semiconductor" text is seen right to me when I look to the Thingy on the table from above.
I put the thingy like I said (on a flat surface) and without removing Thingy from the table surface, I turned it to clockwise and counterclockwise. This movement occurs very problematic results and I can see it on the app, its location is not stable and it jumps.
Then, I put the Thingy on its other (smaller) surface on the table and I follow the same procedure and again the result is problematic just when I exactly do the SAME movement (clockwise and counterclockwise).

This situation really bad for our future project and I cannot overcome it by myself. I don't know actually MPU driver causes this problem, or your SDK or is it a real problem also.

Could you please help me about that.

Thanks.

Here are my steps while testing the issue:

• We get Thingy52 and we use your code in this repository under the path: project\pca20020_s132\arm5_no_packs\ble_app_thingy_s132_pca20020.uvprojx.
• I use Keil and I can build the project with no error or warning
• I use NRFGostudio to program the device. While doing that, I use the hex file that my Keil generated to program application part and I use the soft device s132 hex file under the path: sdk_components\softdevice\s132\hex
• Then I download the app Thingy app to Android and iPhone (results same)
• Then I motion the thingy and observe its motions on the app. My observations are just like mentioned above.

hardcoded value in thingy_sdk_v1.1.0\project\pca20020_s132\main.c

I am trying to add new service to thingy but i spent a lot of time debugging missing to see the hardcoded value.

in main.c->thingy_init()
Please change
ble_params.evt_handler = thingy_ble_evt_handler;
ble_params.p_service_handles = m_ble_service_handles;
ble_params.service_num = 5;

to

ble_params.evt_handler       = thingy_ble_evt_handler;
ble_params.p_service_handles = m_ble_service_handles;
ble_params.service_num       = THINGY_SERVICES_MAX;

This way it is convenient for users to add services by just edit the thingy_config.h file

liblibmplmpu.a missing

this library is missing from the downloaded SDK. I grabbed it from another one of your repositories. This project will not compile with out it.

unreachable statement in ble_app_thingy example

    case thingy_ble_evt_timeout:
        (void)SEGGER_RTT_WriteString(0, RTT_CTRL_TEXT_BRIGHT_GREEN"Thingy_ble_evt_timeout"RTT_CTRL_RESET"\n");
        nrf_delay_ms(5);
        sleep_mode_enter();
        NVIC_SystemReset();   // <- This statement is unreachable
        break;

sleep_mode_enter will never return as it makes the chip go to system off. wakeup will automatically cause a system reset.

Linux install: problems patching Nordic SDK

When installing on a Linux system setup_sdk.sh fails with these errors because the SDK uses DOS EOL but the Thingy52 diff comes out of git with Unix EOL:

patching file components/ble/ble_services/ble_dfu/ble_dfu.c
Hunk #1 FAILED at 88 (different line endings).
Hunk #2 FAILED at 99 (different line endings).
Hunk #3 FAILED at 128 (different line endings).
Hunk #4 FAILED at 141 (different line endings).
4 out of 4 hunks FAILED -- saving rejects to file components/ble/ble_services/ble_dfu/ble_dfu.c.rej
patching file components/ble/ble_services/ble_dfu/ble_dfu.h
// many lines removed
patching file external/segger_rtt/SEGGER_RTT.h
Hunk #1 FAILED at 159 (different line endings).
1 out of 1 hunk FAILED -- saving rejects to file external/segger_rtt/SEGGER_RTT.h.rej

Since upstream patch has only recently been asked to fix this particular line feed combination I worked around it by running:

unix2dos external/sdk_12.1.diff

before sh setup_sdk.sh.

Presense detection feature

Hi,

I bought some thingy for testing. I was thinking the thingy52 could detect presence of a person in a room. E.g. Person enters room. Stays in room. Is this even possible from the hardware side? I thought the thing would have the feature, but could not find it.