NRF9160 & freeRTOS nrf_connect() always times out

[FusedFET]

Hello,
I am working on a project which requires using FreeRTOS with the nrf9160.

Setup:
- Boards tested on:actinius icarus, Thingy91)
- VS-Code with Ceedling as build tool.
- J-Link base
- bsdlib version 0.8.1
- Swisscom SIM

I ported the the Zephry example https_example to both the bare-metal and freeRTOS version.

My issue arises with the nrf_connect() API call which does always return -1, with NRF_ETIMEDOUT (60).

I am doing my developpment on two version:
- A bare-metal version where every thing works.
- A freeRTOS version which does always timeout on nrf_connect(fd, res->ai_addr, sizeof(struct nrf_sockaddr_in));

Attempting to fix this issue, I used the example https_example from the nrf sdk.
Both are identical to the Zephry version with exception of calling directly the nrf9160 bsdlib API.
The bare-metal works a treat, the freeRTOS does not.

Some things I tried:
- I used the bare-metal bsd_os.c in my freertos version, to ensure the issue does not come from there. The error is still there.
- I used a blocking only version (from the sdk porting guide template) of bsd_os.c The error is still there.
- I used the same security tag & certificates for the bare-metal and freertos versions. I can assure the certificate is correct in both applications.
- I know the network is connected, because the app is able to resolve google.com and other websites (to ensure they are not in a cache on the device) before opening the TLS.

Could freeRTOS alter configurations with are done by bsdlib, or alter timings in a significant way?
Does someone have experience with freeRTOS on nrf9160?
Do you have any hints ?

If I get this to work, I'll happily share the freeRTOS implementation.

Sincerly,
Manu

[Karl Ylvisaker]

Hello Manu,

I have forwarded this to our FreeRTOS expert, Susheel. Unfortunately, Susheel is out of office this week, but he will return on Monday.

Best regards,
Karl

[FusedFET]

Thank you :)

[Susheel Nuguru]

Hi Manuel,

The idea, for now, is that we focus our nRF91 solutions on Zephyr RTOS. So I haven't spent any time and energy looking into nRF91 + FreeRTOS. 

I am doing my developpment on two version:
- A bare-metal version where every thing works.
- A freeRTOS version which does always timeout on nrf_connect(fd, res->ai_addr, sizeof(struct nrf_sockaddr_in));

 It seems like one of the tasks in your design has a deadlock (still a guess, but timeouts in one context means that the system is still running except few contexts did not run as they should). It is hard to say that with confidence as we have not tried it ourselves.

Could I ask, why you need to use only FreeRTOS and not Zephyr for your project? Your inputs will help us understand specific needs that we might have missed to see.

[FusedFET]

I might look again for deadlocks, but when I only ran 2 threads with my "bare-metal" bsd-lib.c version on blockign mode, there shoudln't be any deadlocks.

As for Zephry, we prefered FreeRTOS because we are using AWS services and we expected those to be better integrated into FreeRTOS than Zephry. Also we have more experience with workflows based on FreeRTOS and have most of our libs/utils based on it.

[Susheel Nuguru]

- I used the bare-metal bsd_os.c in my freertos version, to ensure the issue does not come from there. The error is still there.
- I used a blocking only version (from the sdk porting guide template) of bsd_os.c The error is still there.
- I used the same security tag & certificates for the bare-metal and freertos versions. I can assure the certificate is correct in both applications.
- I know the network is connected, because the app is able to resolve google.com and other websites (to ensure they are not in a cache on the device) before opening the TLS.

 Where did you get the baremetal version of bsd_os.c? Can you please upload it here so that I can quickly take a look at it?

What is the contexts in which you test call the nrf_connect in baremetal application and context in which you call nrf_connect in FreeRTOS? I would debug and step into nrf_connect in disassemly to see if the code paths taken into the library(for this call only) in baremetal and freertos are similar.

 

Could freeRTOS alter configurations with are done by bsdlib, or alter timings in a significant way?

Yes, there is always a chance that FreeRTOS scheduler behaves differently than Zephyr RTOS scheduler and alters the timings in a significant way.

If you can figure out

1. contexts of call to nrf_connect in baremetal and freeRTOS app, then that would give us some differences that might help narrow down the problem.
2. bsd_os.c, if you are 100% confident on this baremetal variant of the file, then it is fine, if not, then I would spend some time to validate its functionality. I have not seen or tested this before.