Critical bug in nRF Connect SDK v2.1.0 no pin configuration in devicetree header

RE: Critical bug in nRF Connect SDK v2.1.0 no pin configuration in devicetree header

ovrebekk — Fri, 25 Nov 2022 15:32:49 GMT

Hi Georgi

Thanks for sharing the updated forks 🙂

[quote user="Georgi Valkov"]If I build atop the original driver, simple API, low latency and high performance are out of the question.[/quote]

I am confident I can fix the first of those three with my UART async wrapper, but if I can do anything about the other two only testing will tell. I am guessing it won't be as fast as your implementation 😉

[quote user="Georgi Valkov"]Replacing the original driver has never been my intent. I believe users will benefit if given the choice to select one or the other. Of course existing samples will not be compatible, though it is quite easy to support both using #ifdef like I did with connectivity_bridge, or create a dedicated sample. It would be safer to keep UARTE as default. Either way, my fork is now online so people can benefit from it.[/quote]

Yes, having options is great. The more options there are available for Zephyr developers the better, and the standard drivers will never be able to fit all use cases (not to say they can't be improved). Thanks again for making the code available 🙂

[quote user="Georgi Valkov"]A nice thing to do would be to make the UART miniport driver available as a module that can be selected using KConfig. Can you please help me with that?[/quote]

A colleague of mine pointed me to a nice guide online walking through the specifics of making a Zephyr module. He also provides an example module to check out, and a sample showing how to use it. Please have a look here.

I used this as a reference when I 'modularized' my own UART wrapper, that I linked earlier.

Please note that this module doesn't show how to implement device tree bindings, since it doesn't rely on peripheral drivers. I still need to add this to my UART library (hopefully I have some time next week).

If you still need some assistance after looking through Iwasz' example and blog let me know, and I will do my best to help. If you have a lot of questions you might want to open a new ticket again (if you want it to be assigned to me just mention that I already helped you with a similar issue).

Best regards
Torbjørn

RE: Critical bug in nRF Connect SDK v2.1.0 no pin configuration in devicetree header

Georgi Valkov — Tue, 22 Nov 2022 18:23:21 GMT

Hello Torbjørn!

I updated my forks. The UART miniport driver is inside nrf/applications/connectivity_bridge_*/src/uart/

https://github.com/httpstorm/sdk-nrf/tree/2022-11-20

https://github.com/httpstorm/sdk-zephyr/tree/2022-11-20

[quote userid="2116" url="~/f/nordic-q-a/92788/critical-bug-in-nrf-connect-sdk-v2-1-0-no-pin-configuration-in-devicetree-header/396984"]I hate to be negative, but in general getting alternative drivers and such into the official repositories is not very easy.[/quote]

Yes, I've heard this before. Like you said, the changes are too big. And this is intentional. If I build atop the original driver, simple API, low latency and high performance are out of the question. I also understand that such a change is hard to accept in the environment of nRF Connect SDK. That's fine. Replacing the original driver has never been my intent. I believe users will benefit if given the choice to select one or the other. Of course existing samples will not be compatible, though it is quite easy to support both using #ifdef like I did with connectivity_bridge, or create a dedicated sample. It would be safer to keep UARTE as default. Either way, my fork is now online so people can benefit from it.

A nice thing to do would be to make the UART miniport driver available as a module that can be selected using KConfig. Can you please help me with that?

Regarding the nRF9160dk board files: connectivity_bridge is designed to run on Thingy:91. In my environment I also use it on nRF9160dk. In order for this to work, some board changes are needed. A few pins are routed so that nRF9160 and nRF52840 have UART connectivity.

nRF9160 UART0 RX, TX are routed to USB UART0 TX, RX
nRF9160 UART1 TX is routed to nRF52840 UART0 RX
nRF9160 UART1 RX is routed to nRF52840 UART1 TX
nRF52840 UART0 TX is routed to USB UART1 RX
nRF52840 UART1 RX is routed to USB UART1 TX

You likely noticed that UART0-1 on nRF52840 are cross-wired and this is intentional. Data from UART0 RX events is sent to UART0 TX, so anything received from nRF9160 is forwarded to USB UART1. Anything received from USB UART1 goes to nRF9160. This simplifies the connectivity_bridge design, where the common practice is to forward data between interfaces with the same index.

There is one more addition to nRF9160 board files: just like you figured the original API is overcomplicated, a couple of years ago, I needed a simple synchronous send for UART1. So this was my attempt which took over 300 lines of code, see uart_ble.c. Since then I lack any motivation to use the UARTE driver. There is a wisdom saying that API should be easy to use correctly and hard to use incorrectly.

Board changes diff https://github.com/httpstorm/sdk-zephyr/commit/79cffdd6fd352317b2ee55d2864259660c3494b0

BTW You might have noticed I also have connectivity bridge running on nRF52840. No board changes are needed. I just changed the advertised BLE name, because I usually have connectivity bridge running on Thingy:91, nRF9160dk and nRF52840dk at the same time. I need to make it so that instead of keeping 3 dedicated projects differing by the BLE name, I keep only one, and the actual name is selected by the target board. The code is identical.

RE: Critical bug in nRF Connect SDK v2.1.0 no pin configuration in devicetree header

ovrebekk — Tue, 22 Nov 2022 15:22:18 GMT

Hi Georgi

Thanks for sharing your latest driver. I haven't been able to try it out yet, but I took a look at the code.

A challenge with getting something like this into the SDK is that it is a complete rewrite of the current UART driver, basically replacing what is already there.

For that to make sense it would basically have to be able to improve on the existing driver for all use cases across all nRF devices, and it would also need to follow the coding guidelines defined by Zephyr, and the standard device driver model that all Zephyr drivers incorporate.

My UART driver by comparison is just a small wrapper on top of the UART ASYNC driver, and don't require very large changes to the existing framework.

When implementing changes to Zephyr or any of the other repositories under the nRF Connect SDK umbrella it is also recommended to make a fork of the original repository to your own Github account, and implement the changes on this fork.

Then you can easily generate a patch showing the difference between the original repository and your own changes, and in case you want to suggest an update to the upstream repositories you can issue a pull request.

I hate to be negative, but in general getting alternative drivers and such into the official repositories is not very easy. If there is a problem with the official driver then this should be fixed in that driver, rather than having multiple competing drivers in the same repository.
If you could implement your driver as a patch though then it would make it easy for people to try it out, and easy for you to patch it in after downloading the SDK, simplifying the process of adding the driver to an existing sample.

By the way, I noticed you also had board files included in the zip. What did you change in the board files?

Best regards
Torbjørn

RE: Critical bug in nRF Connect SDK v2.1.0 no pin configuration in devicetree header

Georgi Valkov — Mon, 21 Nov 2022 09:17:45 GMT

Thanks Torbjørn! The new ticket is here:
Use BLE driver and stack outside nRF Connect SDK

I made a tiny update to my driver.

devzone.nordicsemi.com/.../uart_5F00_miniport-2022_2D00_11_2D00_20.7z

RE: Critical bug in nRF Connect SDK v2.1.0 no pin configuration in devicetree header

ovrebekk — Mon, 21 Nov 2022 08:48:41 GMT

Hi Georgi

[quote user="Georgi Valkov"]I've been looking for information how the BLE driver and stack are organised in the build system. I would like to use them with a different OS. My goal would be to find all related files and copy them outside the SDK. Then I can provide all necessary API which Zephyr provides and build a library using arm-none-eabi-gcc and make. Any help on that would be very helpful.[/quote]

Could you open a new ticket on this?

This sounds like a pretty complex issue, and the case is getting pretty long already (the devzone is not really designed for handling multiple different issues in the same case).

I will have to get back to you on the UART example, but I will take a look at it and get back to you in a day or two.

[quote user="Georgi Valkov"]Thank you very much! Indeed despite of the many issue, I can confirm that the Nordic team has always been very kind and helpful. [/quote]

That is good to hear 🙂

Best regards
Torbjørn

RE: Critical bug in nRF Connect SDK v2.1.0 no pin configuration in devicetree header

Georgi Valkov — Thu, 17 Nov 2022 09:48:52 GMT

Hello Overbekk!

[quote userid="2116" url="~/f/nordic-q-a/92788/critical-bug-in-nrf-connect-sdk-v2-1-0-no-pin-configuration-in-devicetree-header/396041"]As an example the BLE heart rate sample in Zephyr is 130 lines long, compared to close to a 1000 lines for the equivalent nRF5 SDK example, and a lot of this is down to the simpler Bluetooth API's. [/quote]

I've been looking for information how the BLE driver and stack are organised in the build system. I would like to use them with a different OS. My goal would be to find all related files and copy them outside the SDK. Then I can provide all necessary API which Zephyr provides and build a library using arm-none-eabi-gcc and make. Any help on that would be very helpful.

[quote userid="2116" url="~/f/nordic-q-a/92788/critical-bug-in-nrf-connect-sdk-v2-1-0-no-pin-configuration-in-devicetree-header/396041"]if for instance you want to make your own device driver this is quite challenging until you understand how the build system works[/quote]

I agree! I actually implemented my own UART miniport driver, which can work on bare metal, or integrate with an OS such as Zephyr or nano RTOS so that tasks sleep while waiting for the hardware. The driver was designed with a simple API, high efficiency, low latency and portability in mind. So it can work with any RTOS that provides task wait and wake from interrupt API. Attached below is the source code integrated in connectivity_bridge. Can you please help me make it into a library for nRF Connect SDK? Ideally the user should be able to disable UARTE and enable UART miniport through KConfig, then use the driver API. It would be nice if we can make it part of the SDK to benefit everyone who wants to use it.

I did a performance comparison between original and modified versions of connectivity bridge. Consider an external CPU is sending a lot of data, keeping the UART RX busy 100% of the time at 115200 baud rate, e.g.

for (int i = 0; 1; i++) printf("UART test %8i\n", i);

With the original connectivity_bridge the BLE client receives large packets with a huge delay between them. With the modified code attached below the packet size is adaptive based on load, keeping latency as low as possible. CPU usage is also highly reduced. One change I had to make was to move the BLE send code to a dedicated higher priority task, instead of using the system work queue. The work queue would choke when a lot of data is received, especially if USB UART is also connected to a computer and in use. In my test I used connectivity_bridge_52840 which runs on nRF52840dk.

devzone.nordicsemi.com/.../uart_5F00_miniport-2022_2D00_11_2D00_07.7z

[quote userid="2116" url="~/f/nordic-q-a/92788/critical-bug-in-nrf-connect-sdk-v2-1-0-no-pin-configuration-in-devicetree-header/396041"]I am actually working on my own wrapper for the UART ASYNC driver, in order to simplify UART handling overall, handle application buffering of data and remove the need for dynamic memory allocation. Feel free to have a look at the driver here if you're interested. I'm planning to get it into the nRF Connect SDK once I have had more time to stress test it, and for what it's worth it only has two public functions and a single callback, so it should satisfy the 'simple API' criteria[/quote]

That's great! Makes me curious if you can compare the performance to my driver? I'll be happy to see both available in the SDK. Since my code has no external dependencies, it should be easy to integrate. One important note about UART miniport: send and receive calls are somewhere in between synchronous and and asynchronous. As long as the driver buffer has enough space to store all TX data, the call returns immediately. If the buffer is full, the call returns as soon as all data is copied, transmission continues using DMA on the background. for RX, incoming data is stored in the RX buffer. A recv request returns as soon as any data is available to read, otherwise it blocks (it can also be configured to wait until all requested data is received). The benefit of this design is that the user can easily implement recv, process, send on one task without any risk of dropping data. And since there is no need for synchronisation between tasks or queues, this results in a very simple and reliable code.

[quote userid="2116" url="~/f/nordic-q-a/92788/critical-bug-in-nrf-connect-sdk-v2-1-0-no-pin-configuration-in-devicetree-header/396041"]And in general never hesitate to get in touch with us regarding any issues you find in the SDK. It will never be perfect, and we can't satisfy every request, but it is always better to report something to us rather than just get frustrated on your own[/quote]

Thank you very much! Indeed despite of the many issue, I can confirm that the Nordic team has always been very kind and helpful. 🙂

RE: Critical bug in nRF Connect SDK v2.1.0 no pin configuration in devicetree header

ovrebekk — Wed, 16 Nov 2022 15:10:30 GMT

Sorry for the slow response from the Nordic side. I took over this case from Håkon a while back, and have been observing the discussion from the side line without taking part.

It has been a bit of a bumpy ride with the nRF Connect SDK introduction no doubt, but it is getting better day by day and we are putting a lot of effort into helping people get through the initial hurdle of getting started with it.

My personal experience getting into the SDK is that the initial learning curve is very steep, but once you start to understand how the various build systems, API's etc are put together, and understand how to use the Zephyr RTOS to the best effect, then the productivity goes up considerably compared to the nRF5 SDK.

As for complexity I believe this is a bit of a mixed bag. The build system is certainly more complex, and if for instance you want to make your own device driver this is quite challenging until you understand how the build system works, but I feel that most of the API's are clear and concise.

As an example the BLE heart rate sample in Zephyr is 130 lines long, compared to close to a 1000 lines for the equivalent nRF5 SDK example, and a lot of this is down to the simpler Bluetooth API's.

Project configuration with Kconfig is generally a lot easier than working with sdk_config.h too, and moving from one chip to another is easier because of the board architecture.

Regarding UART drivers I agree there is some work to be done there. I am actually working on my own wrapper for the UART ASYNC driver, in order to simplify UART handling overall, handle application buffering of data and remove the need for dynamic memory allocation. Feel free to have a look at the driver here if you're interested. I'm planning to get it into the nRF Connect SDK once I have had more time to stress test it, and for what it's worth it only has two public functions and a single callback, so it should satisfy the 'simple API' criteria 😉

I don't know if this driver would help with the connectivity_bridge sample though, the main focus has been on the peripheral_uart sample.

And in general never hesitate to get in touch with us regarding any issues you find in the SDK. It will never be perfect, and we can't satisfy every request, but it is always better to report something to us rather than just get frustrated on your own 🙂

Regarding LTS releases this is something that we are considering, but we don't have any concrete plans to share yet unfortunately.

Best regards
Torbjørn

RE: Critical bug in nRF Connect SDK v2.1.0 no pin configuration in devicetree header

Georgi Valkov — Tue, 08 Nov 2022 19:28:09 GMT

jtrueb

[quote userid="90890" url="~/f/nordic-q-a/92788/critical-bug-in-nrf-connect-sdk-v2-1-0-no-pin-configuration-in-devicetree-header/391850"]I'm not ready to switch off of the NRF Connect SDK at the moment. I want an RTOS that can be certified similar to the NRF5 SDK. I want tools and build systems that work (not SEGGER).[/quote]

Alas I cannot offer certification, and the features are pretty basic at the moment. arm-none-eabi is used to build an .elf image.

[quote userid="120604" url="~/f/nordic-q-a/92788/critical-bug-in-nrf-connect-sdk-v2-1-0-no-pin-configuration-in-devicetree-header/391963"]It sounds like you are more tolerant of release train and security issues since you are considering a new RTOS.[/quote]

Honestly, all I have for nRF52840 is a low latency UART driver with DMA. Whenever I need the BLE radio, I'm forced to use nRF Connect with my driver, because the original is too complicated, apart from reliability and latency issues.

[quote userid="90890" url="~/f/nordic-q-a/92788/critical-bug-in-nrf-connect-sdk-v2-1-0-no-pin-configuration-in-devicetree-header/391850"]I have become accustomed to scrolling through the Known Issues because so many of them are relevant to core functionality of an application. [/quote]

One issue I have with Zephyr is how overcomplicated everything is. This leads to mistakes. I started nano RTOS, because I needed simple API and concurrent tasks for a project based on Arduino. I do my best to consider security and reliability factors in my designs. And I follow the rule that API should be easy to use correctly and hard to use incorrectly. Many pitfalls arise from not knowing how to use a certain functionality.

[quote userid="120604" url="~/f/nordic-q-a/92788/critical-bug-in-nrf-connect-sdk-v2-1-0-no-pin-configuration-in-devicetree-header/391963"]How are you handling CVEs?[/quote]

For Zephyr I have not used it professionally since we lost the project due to the many SDK issues. Nowadays I use it to run a few projects of mine as a hobby. At a later point I discovered a BLE exploit and got a bounty. I never imagined I would need to write an UART driver and make other changes to connectivity_bridge to get a stable link between UART and BLE.

helsing I'm having some issues writing this replay. Some quotes include my name instead of jtrueb. Also quotes appear three times. I get the impression this DevZone has been quite buggy in the past years. Do ask the web developers to have a look into that and try writing more reliable code in the future. Also note jtrueb complaining about formatting.

RE: Critical bug in nRF Connect SDK v2.1.0 no pin configuration in devicetree header

jtrueb — Fri, 21 Oct 2022 20:53:18 GMT

Sorry I don't know why the formatting is so bad there. It didn't look like that in preview.

RE: Critical bug in nRF Connect SDK v2.1.0 no pin configuration in devicetree header

jtrueb — Fri, 21 Oct 2022 20:52:01 GMT

I have also migrated a number of older projects from NRF SDK to NRF Connect SDK and NRF Connect SDK to NRF Connect SDK. I would estimate that on the average I also experienced similar schedule effort regarding the migration burden. Not mentioned yet is the known issues or regressions that I encountered during those upgrade attempts. For example, the HF clock power regression was immediately obvious on the power profiler. Another problematic one was the TX power level. I have become accustomed to scrolling through the Known Issues because so many of them are relevant to core functionality of an application. The PINCTRL issue earlier is a new known issue in 2.1.0.

jtrueb Thank you for your message and letting me know I am not alone. Would you be interested in testing nano RTOS? I recently wrote an light-weight operating system, which is very responsive. It is a new project of mine, and I had no time to create a web page yet.

I'm not ready to switch off of the NRF Connect SDK at the moment. I want an RTOS that can be certified similar to the NRF5 SDK. I want tools and build systems that work (not SEGGER). I want to debug my team's code, not someone else's. I want the other developers on my team to be able to use the same environment, toolchain and code to have reproducible builds and consistent bug reports. I want to have a path forward to using new products like the NRF53 series. I think Nordic + Zephyr RTOS can be all of that long term.

What I really want is for the NRF Connect SDK to stabilize. I am happy with the features that are already there (targeting the mature NRF52 series) and just want the sweeping changes and bugs to stop. I haven't been using any new SDK features for a while. I have to keep upgrading at the moment because the tooling keeps changing, stuff is not back-ported, and issues keep becoming blockers.

I wish that the SDK came with some commitment or compliance to quality that was enforced. Zephyr has an auditable LTS release train and is working towards MISRA compliance. Why is the NRF Connect SDK not aligned with the LTS release train for Zephyr? I am really hoping to stop all the upgrading and get an LTS of the SDK.

One thing about the issue you hit while upgrading was that you bumped a major version, so the LTS stuff is less relevant in this case. It sounds like you are more tolerant of release train and security issues since you are considering a new RTOS.

How are you handling CVEs? https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/security_chapter.html

There aren't any SDK references to vulnerabilities or hot fixes, etc. Many of the Zephyr CVEs are resolved like 'This has been fixed in main for v3.0.0' and backported (to a version that you can't install with the Toolchain Manager).

RE: Critical bug in nRF Connect SDK v2.1.0 no pin configuration in devicetree header

helsing — Fri, 21 Oct 2022 14:06:23 GMT

Hi Georgi, sorry for the late reply.

[quote user="Georgi Valkov"]I was able to get the pin configuration working during the weekend. [/quote]

Great to heat that you were able to get things working.

[quote user="Georgi Valkov"]I created a new case for connectivity_bridge: malfunction due to improper use of system work queue[/quote]

Thank you for creating a new case as this makes it easier for others to follow.

Thank you for your feedback on the SDK, I am forwarding this to the relevant teams.

RE: Critical bug in nRF Connect SDK v2.1.0 no pin configuration in devicetree header

Georgi Valkov — Fri, 21 Oct 2022 11:12:12 GMT

I created a new case for connectivity_bridge: malfunction due to improper use of system work queue
connectivity_bridge: malfunction due to improper use of system work queue

[quote userid="120604" url="~/f/nordic-q-a/92788/critical-bug-in-nrf-connect-sdk-v2-1-0-no-pin-configuration-in-devicetree-header/391745"]If the SDK has software maturity levels that are "end product" quality, then things like breaking pin configuration, removing nrfx layer functionality, or requiring significant migration burden need to be front and center in the documentatio prior to release.[/quote]

True. I started working on a project with nRF Connect SDK in 2018. Needless to say we lost the project a couple of years later. We faced an endless amount of serious issues. Put simply basic stuff does not work.

[quote userid="120604" url="~/f/nordic-q-a/92788/critical-bug-in-nrf-connect-sdk-v2-1-0-no-pin-configuration-in-devicetree-header/391745"]To my understanding, this means that many nrfx interfaces are not tested at all. This makes migrating legacy NRF SDK code to NRF Connect SDK either impossible or a complete re-development in my experience thus far.[/quote]

My experience all shows that any change to the SDK requires a tremendous amount of work to port even simple applications. It took me two weeks to adapt to the new pinctrl and devicetree changes, and fix a serious flaw in connectivity bridge (link above).

Indeed testing is a very important part of development, and it is an even greater responsibility for SDKs to be robust. A wise man once said that a good API is easy to use correctly and hard to misuse. nRF Connect SDK is quite the opposite. Overcomplicated and resource demanding. My first attempt to use an UART in nRF Connect SDK resulted in 300 lines of complex code copied from an existing sample. Most users need a simple send and don't want to be bothered to service interrupts.

In connectivity_bridge, data travels through multiple hops from receive to send side. Each doing it's own buffer management. With my UART driver implementation we can receive and send in the same task without any risk of dropping data. The driver takes care of any background processing allowing the task to issue more send and receive requests.

jtrueb Thank you for your message and letting me know I am not alone. Would you be interested in testing nano RTOS? I recently wrote an light-weight operating system, which is very responsive. It is a new project of mine, and I had no time to create a web page yet.

RE: Critical bug in nRF Connect SDK v2.1.0 no pin configuration in devicetree header

jtrueb — Thu, 20 Oct 2022 19:31:31 GMT

There is a need to break in order to fix and improve for the future of the RTOS and SDK; however, I agree the SDK software maturity levels don't match my expectations.

If the SDK has software maturity levels that are "end product" quality, then things like breaking pin configuration, removing nrfx layer functionality, or requiring significant migration burden need to be front and center in the documentatio prior to release. Yet, the emphasis cannot be only documentation; it must also focus on verification with NRF products, not just the general Zephyr tests for dev kits.

Take for example, pinctrl, which is the crux of your issue, several of my issues, and a number of others. It came with a migration guide in the SDK and an overview in the RTOS, I applaud the content created there as it is more usable than much of the older documentation with Zephyr. The problem lies in the gap between documentation, implementation, and test. Consider further the fallout of changing pin configuration like with serial interfaces like the TWIM drivers. Pinctrl broke the ability to use nrfx_twim through the nrfx interface. The cause is that the new configuration pattern can no longer generate the configuration and compile it. CONFIG_NRFX_TWIM0 can no longer be assigned without using a separate board dts (overlays are broken) and i2c_nrfx_twim doesn't compile with CONFIG_PINCTRL disabled.

Here is a snippet of code that shows that nrfx_twim was never compiled without pinctrl prior to releasing the SDK that broke usage of the ability to compile the nrfx_twim interface. This code is 3 months old. To my understanding, this means that many nrfx interfaces are not tested at all. This makes migrating legacy NRF SDK code to NRF Connect SDK either impossible or a complete re-development in my experience thus far.

I do not intend to discourage future changes. I want to emphasize and echo the struggles of a consumer of the SDK who isn't alone. I have experienced difficulty migrating release after release after release like no other beta software, but the documentation and tooling is getting better and the bugs less severe. The new developer academy and improved NRF Connect SDK website have been a welcome improvement as well.

Sorry this wasn't so helpful for your points 3 and 4.

RE: Critical bug in nRF Connect SDK v2.1.0 no pin configuration in devicetree header

Georgi Valkov — Mon, 17 Oct 2022 12:36:30 GMT

Thank you, Helsing!

I was able to get the pin configuration working during the weekend. Indeed I used pinctrl_apply_state and created a pinctrl_dev_config structure.

Now my modified version of connectivity_bridge works on nrf9160dk, but I'm facing an issue on Thingy:91. The UART0 to USB UART bridge works until a BLE client connects. Then two more messages are sent to BLE, and also to the USB UART, and then all communication stops. So far I discovered that all uart_rx_slab buffers are consumed, because app_event_handler is not called. Once the BLE client disconnects, the communication is resumed and I can see more messages from UART0 to USB UART. I have the gnss sample running on nrf9160 -> UART0 nrf52840 -> USB UART and BLE. The same code works without issues on SDK v1.9.1.

If I run another sample on nrf9160, or if I use the original connectivity_bridge everything works fine.

I am having hard time debugging this, because whenever I set a breakpoint and try to step in the code, the board reboots. I recall there is some evil code in the BLE driver, that reboots the CPU if not called within a certain deadline, so once we break into the debugger the deadline is missed, and the board will reboot as soon as we try to step in the debugger. This makes debugging impossible. In addition to that, I'm using an nrf9160dk as a JTAG, and there is bug in the board controller firmware, causing it to reboot 50% of my attempts to reflash the Thingy. So I need to restart VS code every time I change the code, otherwise I lose the RTT console.

devzone.nordicsemi.com/.../390804

Can you please help me this issue?

devzone.nordicsemi.com/.../2022_2D00_10_2D00_17.7z

RE: Critical bug in nRF Connect SDK v2.1.0 no pin configuration in devicetree header

helsing — Mon, 17 Oct 2022 09:17:49 GMT

Hi Georgi!

For migration of the uart driver you may see \zephyr\drivers\serial\uart_nrfx_uarte.c. If you search for "CONFIG_PINCTRL" you can see the pin control approach.

RE: Critical bug in nRF Connect SDK v2.1.0 no pin configuration in devicetree header

helsing — Fri, 14 Oct 2022 14:57:10 GMT

Hi Georgi, I will get back to you over the weekend.

RE: Critical bug in nRF Connect SDK v2.1.0 no pin configuration in devicetree header

Georgi Valkov — Thu, 13 Oct 2022 14:56:01 GMT

Hello Helsing!

Thank you for the links! Now I understand how the dts files should be configured, and it seems I had already configured mine properly. Unfortunately the article does not describe how to port my UART driver code. How do I access pin configuration in C code?

RE: Critical bug in nRF Connect SDK v2.1.0 no pin configuration in devicetree header

helsing — Wed, 12 Oct 2022 21:16:53 GMT

Hello Georgi,

The Migration notes for nRF Connect SDK v2.0.0 mentions the Pin control transition. Have you had a look at the Pin control page? Please also see the section about Migration of the devicetree files.

Best regards,

Håkon