Issue custom GATT streaming in the firmware when building in release mode.

[Caio Camargo]

Hello Nordic Team. 


I'm currently facing an issue when building in release mode (CONFIG_LOG, SERIAL, CONSOLE disabled). The issue is that after a random time (no longer than 5 minutes) the streaming value in the custom GATT Service suddenly stops. However, the firmware keeps functioning in that I'm able to read other Characteristics, disconnect, re-connect to the device but the thread in charge of this work never captures the semaphore triggered by the timer. This issue does not happen when building and testing over debug mode either with RTT BUS connected or disconnected from the DK I use to upload the fw. I suspect that it may be something related to some config when building using a release.conf file. 

In the path to try to solve this, I saw this post on dev zone but didn't solve this. 

Any help on this will be highly appreciated. 

In attach, is the schematic and the firmware files.

 project3.zipMeasure_resistance-new (1).pdf

[Vidar Berg]

Hello,

I wanted to compare the build configurations from the build_debug and build_lowpower output, but I see that the latter is missing the configuration files. Would you mind rebuilding the lowpower version and upload the folder again?

Best regards,

Vidar

[Caio Camargo]

Hello Vidar, thank you for a fast reply. 

To give more info this is how I'm building passing optimization levels for each build:



Here I'll compressed both builds in one file zip. 

both_builds.zip

[Vidar Berg]

Thank you. I see now that this and the previous version of the lowpower build were built without sysbuild enabled for some reason (should be enabled by default). For consistency, I suggest you force sysbuild on by selecting the checkbox here:

I also see you have selected CONFIG_CLOCK_CONTROL_NRF_K32SRC_20PPM with the lowpower build while using the internal RC oscillator. The problem with that is that the RC oscillator in HW only has a 500 ppm accuracy. This will eventually lead to connection problems as the BT stack will fail to correctly compensate for the clock drift. You can comment this line to let it default to CONFIG_CLOCK_CONTROL_NRF_K32SRC_500PPM.

Does the led_on() indicaten in your timer callback confirm whether the callback stops being invoked or not? 

Best regards,

Vidar

[Caio Camargo]

I'm currently testing this changes. However to answer you question, yes it's confirm either where it's stop or somewhere else, as I said, the firmware keeps running, but the thread that takes the semaphore never take. I started to think of different threads priorities, then put every thread to the same and let the scheduler to its jobs, but no success. Still get stuck with the LED ON. 

[Vidar Berg]

Please let me know if it changes anything. Would also be good if you could try to debug this a bit further. For example, would enabling logging in the release configuration make it work again?