Update Nordic SDK for nrf52 series to latest version including softdevice

[dlfryar-zz]

Description

• Type: Enhancement
• Priority: Major

---

Target
nrf52832 & nrf52840

---

Enhancement

Latest softdevice and fixes with current release.

[0xc0170]

@dlfryar Are there any specific fixes/features you would like to use from the latest softdevice?

@ARMmbed/team-nordic

[joost-productize]

SDK 14.1 + corresponding softdevice s132 5.0.x allows secure DFU with bonds.

[dlfryar-zz]

In 140, memory requirements reduced, MBR updates bug fixes, flash size increase, and being closer to a production version.

[rerickson1]

Any time frame for when this will be complete?

[dlfryar-zz]

Mbed OS SDK updates happening here

[saedelman]

We are having continual stability issues with respect to NRF52832 with mbed-os 158. There appears to be a race condition in the Nordic TWI driver (i2c_api.c) that is triggered when an I2C device clock stretches in the order of 10ms or more (as is the case with the Ublox M8 GPS). We've tried to create a "user space" I2C library by bit-banging a pair of DigitalInOut pins, but this locks up the thread also as soon as the pin is defined. Incidentally, we can make the application limp along if we do not call "Thread::wait" in any thread and instead loop around osKernelGetTickCount() but this severely increases the power consumption and decreases overall responsiveness. I should point out that if we stop querying the GPS and substitute reasonable data, there is no stability issue. If we set the I2C_TIMEOUT_VALUE_US compile time define to 500 we can get data from our other sensors on the I2C bus, but not from the GPS and the OS remains stable, so the issue is related to holding some kind of kernel lock in the TWI driver for longer than the RTOS likes. Lastly, removing DEVICE_I2C_ASYNC from the device capabilities list (but leaving DEVICE_I2C) breaks the compile.

[0xc0170]

@saedelman Can you create a new issue with this description? I imagine that device async should be one (should be functional). And another one regarding I2C race condition

[saedelman]

Yes, I will. I ended up replacing the Nordic i2c_api.c HAL driver with our own bit banged version and this solved the stability problem. I will put together a test case program and submit a PR.

[saedelman]

After additional testing, we have determined that the most likely culprit to the stability issues we are seeing with the NRF52832 and mbed-os 158 is the sleep handling. When compiling with DEVICE_SLEEP removed from the device capabilities (device_has), the stability issues disappear. The fact that using a bit-banging I2C library instead of the hardware I2C meant that we spent more time keeping the CPU busy and therefore less likely to trigger an occasion where all threads were in Thread::wait() allowing sleep to be entered and crashing the app. This is confirmed by putting the original Nordic i2c_api.c hal driver back and not seeing any stability issues as long as DEVICE_SLEEP is removed from the compile options. I believe this is related to #5647 and #4927.

[pan-]

@saedelman Could you provide a more detailed description of your system architecture ? I'm mostly interested by the number of concurrent threads, the number of devices addressed on the I2C bus and the type of primitives used to wait or synchronize these threads. Could you also indicates the functions of the i2c API used ?

It would be interesting to test with #5889 which solved a system wide concurrency issue in timing primitives.

[saedelman]

@pan - we have a custom PCB with Taiyo Yuden module with nRF52832, and 4 physical devices on the same I2C bus (GPS, IMU, battery state-of-charge monitor, air pressure and temperature sensors). We're also using SPI for SD card access as well as a speech processor. We're primarily using Mutex and Semaphores to synchronize data between threads. With respect to the I2C API, we primarily use read/write/start/stop and have exposed the "i2c_reset()" hal function to the I2C class, as this appeared to be necessary when the GPS hangs the bus.

You noted #5889, we have long suspected that there is an issue with the use of (ticker_read(get_us_ticker_data()) - t0) < I2C_TIMEOUT_VALUE_US in the Nordic i2c_api.c hal driver to detect an I2C timeout. We replaced it with the less granular osKernelGetTickCount() and saw less NAKs for the same timeout duration (which we had set to 25ms to accommodate the insanely long clock stretch by the Ublox GPS).

How do I import #5889 into mbed-os 158 that we are currently using and does #5889 work with the NRF52_DK target also?

[pan-]

@saedelman #5889 is a global fix; the issue was affecting all mbed OS targets. You can get it with the following commands:

git fetch 
git cherry-pick 6d3ba94f98f71ceb3944175db4ea5db917645c8c

Looking rapidly at the I2C implementation I've noticed several potential issues: I2C::read(int ack) and I2C::write(int data) does not acquire the bus and therefore don't set the appropriate bus frequency. The bus configuration set in I2C::transfer can be changed while the transfer is ongoing and finally application code has to make sure that its I2C instance is locked before initiating a transaction that contains I2C::start or I2C::stop.

[saedelman]

@pan - thanks for the clarification. I have merged it with our code base. When troubleshooting our stability issue, we moved all of the I2C functions into a single thread, so locking is not necessary.