libuarte: Connection between NRF9160dk and NRF52840

RE: libuarte: Connection between NRF9160dk and NRF52840

Vidar Berg — Fri, 24 Sep 2021 21:21:07 GMT

Hi Brett,

I'm glad to hear that it works, thank you for the update. This isn't just a trap for new players - I was not aware of it either 🙂 I have never used printf's with RTT though, only UART.

Cheers

Vidar

RE: libuarte: Connection between NRF9160dk and NRF52840

Brett — Fri, 24 Sep 2021 20:52:58 GMT

Hi Vidar,

Thanks ! That was the answer, printf() was blocking - all appears to be working now.

Trap for new players !

regards

-brett

RE: libuarte: Connection between NRF9160dk and NRF52840

Vidar Berg — Thu, 23 Sep 2021 09:57:28 GMT

Hi Brett,

I have hopefully figured it out now: in your project you used printf's to print the debug message over RTT, which unlike the NRF_LOG_* macros, are blocking. That is, printf() won't return until the debug message has been received by the debugger.

I think this must be the reason why it only worked when you did SES Build->Debug in the beginning. Please try to use the NRF_LOG_* macros instead to confirm.

I also made some changes to my 9160 project in the process. Here is my updated version:

devzone.nordicsemi.com/.../3757.uart_5F00_52840_5F00_9160.zip

RE: libuarte: Connection between NRF9160dk and NRF52840

Brett — Wed, 22 Sep 2021 20:04:47 GMT

Thanks Vidar, appreciate you having a look at it for me.

I can send over my 9160 code as well if that helps at all.

RE: libuarte: Connection between NRF9160dk and NRF52840

Vidar Berg — Tue, 21 Sep 2021 16:45:43 GMT

Hi Brett,

I have to spend some more time on this, unfortunately. I realized that my UART implementation on the 9160 isn't working properly either when I started testing with your example. Will try to get you an update tomorrow.

Cheers,

Vidar

RE: libuarte: Connection between NRF9160dk and NRF52840

Brett — Mon, 20 Sep 2021 20:42:16 GMT

Hi Vidar,

For now I am only trying to send data from the 52840 to the 9160 - so the flow-control should not be an issue ?

I have attached the code that I have, if you are able to try this on your board to see if it works for you, and/or if there is something obvious I have missed.

Note; This code is a cut/paste from one of the BLE examples which I have not completely cleaned up yet.
This code has also been cut down to send `1` every 5 seconds over the UART connection, so your 9160 receiver should be able to get the message and log it.

cheers

-brett

devzone.nordicsemi.com/.../app_5F00_libUARTE.tar.gz

RE: libuarte: Connection between NRF9160dk and NRF52840

Vidar Berg — Tue, 14 Sep 2021 09:21:36 GMT

Hi Brett,

Your configuration looks fine. You have to select TIMER1 like you did as TIMER0 is reserved to the Softdevice.

[quote user="Brett"]Q: I am using the s340 soft device, doest that influence the clock or timers I need to use ?[/quote]

The only difference is that you can't use TIMER0 like mentioned above.

[quote user="Brett"]Q: Does the SES debug provide clock differently than not using it ?[/quote]

The HF clock is kept always on while in debug mode, but you will get the same effect by calling sd_clock_hfclk_request() like I suggested in my initial reply. So I don't think the issue is clock related.

Have you enabled flow control on the 52840 side like I did in my example? I noticed you only had it on the 9160 in the initial code you posted. In that case, do you get a "busy" error if you try to send data from the 9160?

Cheers,

Vidar

RE: libuarte: Connection between NRF9160dk and NRF52840

Brett — Sun, 12 Sep 2021 06:26:16 GMT

Hi Vidar,

Your code by itself works fine, so I have tried to identify any differences between them.

Both lots of settings basically the same now (not identical as I have softdevice/ANT+ code) and the same thing happens, I can run the code in SES-Debug mode and all works, but as soon as I just run or power cycle the unit, I dont get the data through.

Q: I am using the s340 soft device, doest that influence the clock or timers I need to use ?

Q: Does the SES debug provide clock differently than not using it ?

The obvious difference I have between the 2 code bases is below, hence the reason for my timer/RTC question.

Mine:

NRF_LIBUARTE_ASYNC_DEFINE(libuarte, 0, 1, 2, NRF_LIBUARTE_PERIPHERAL_NOT_USED, 255, 4);

Yours:

NRF_LIBUARTE_ASYNC_DEFINE(libuarte, 0, 0, 0, NRF_LIBUARTE_PERIPHERAL_NOT_USED, 255, 3);

cheers

-brett

RE: libuarte: Connection between NRF9160dk and NRF52840

Brett — Fri, 10 Sep 2021 20:08:29 GMT

Hi Vidar,

It worked on the nrf9160df_nrf9160, and after I copied the overlay to nrf9160dk_nrf9160ns.overlay it works as well. (note: I used nrf9160dk_nrf9160ns and not nrf9160dk_nrf9160_ns).

I will work from this to see if I can work out what the differences are.

cheers

-brett

RE: libuarte: Connection between NRF9160dk and NRF52840

Vidar Berg — Fri, 10 Sep 2021 08:03:02 GMT

Hi Brett,

Can you try to build for "nrf9160dk_nrf9160" instead? Seems like the UART instance I selected won't initialize in the non-secure domain for some reason.

Cheers

Vidar

Update: I had forgotten to include an overlay file for nrf9160dk_nrf9160_ns so that's why it didn't work. To fix this you can make a copy of the nrf9160dk_nrf9160.overlay file in "boards" and and name it nrf9160dk_nrf9160_ns.overlay.

RE: libuarte: Connection between NRF9160dk and NRF52840

Brett — Fri, 10 Sep 2021 07:01:20 GMT

Hi Vidar,

I compiled you code (west build -c -p -b nrf9160dk_nrf9160ns), which worked fine and the flash went fine, but on the 9160 I get the following error.

BTW: The 52840 complied and loaded fine.

*** Booting Zephyr OS build v2.6.0-rc1-ncs1 ***
Flash regions Domain Permissions
00 01 0x00000 0x10000 Secure rwxl
02 31 0x10000 0x100000 Non-Secure rwxl

Non-secure callable region 0 placed in flash region 1 with size 32.

SRAM region Domain Permissions
00 07 0x00000 0x10000 Secure rwxl
08 31 0x10000 0x40000 Non-Secure rwxl

Peripheral Domain Status
00 NRF_P0 Non-Secure OK
01 NRF_CLOCK Non-Secure OK
02 NRF_RTC0 Non-Secure OK
03 NRF_RTC1 Non-Secure OK
04 NRF_NVMC Non-Secure OK
05 NRF_UARTE1 Non-Secure OK
06 NRF_UARTE2 Secure SKIP
07 NRF_TWIM2 Non-Secure OK
08 NRF_SPIM3 Non-Secure OK
09 NRF_TIMER0 Non-Secure OK
10 NRF_TIMER1 Non-Secure OK
11 NRF_TIMER2 Non-Secure OK
12 NRF_SAADC Non-Secure OK
13 NRF_PWM0 Non-Secure OK
14 NRF_PWM1 Non-Secure OK
15 NRF_PWM2 Non-Secure OK
16 NRF_PWM3 Non-Secure OK
17 NRF_WDT Non-Secure OK
18 NRF_IPC Non-Secure OK
19 NRF_VMC Non-Secure OK
20 NRF_FPU Non-Secure OK
21 NRF_EGU1 Non-Secure OK
22 NRF_EGU2 Non-Secure OK
23 NRF_DPPIC Non-Secure OK
24 NRF_REGULATORS Non-Secure OK
25 NRF_PDM Non-Secure OK
26 NRF_I2S Non-Secure OK
27 NRF_GPIOTE1 Non-Secure OK

SPM: NS image at 0x10000
SPM: NS MSP at 0x20010a80
SPM: NS reset vector at 0x11885
SPM: prepare to jump to Non-Secure image.
*** Booting Zephyr OS build v2.6.0-rc1-ncs1 ***
uart_init() failed. (err: -6)

cheers

-brett

RE: libuarte: Connection between NRF9160dk and NRF52840

Vidar Berg — Wed, 08 Sep 2021 10:28:07 GMT

OK, thanks for confirming. I've set up a simple loopback test here now with libuarte running on the 52840 and the Zephyr async driver on the nRF9160 and that seems to work fine. Could you try these 2 projects on your end and see if it works for you as well? Maybe you can spot what we're doing differently.

devzone.nordicsemi.com/.../uart_5F00_com_5F00_test_5F00_52840_5F00_9160.zip

-Vidar

Edit: This example selected the wrong UARTE instance. Use the updated projects I uploaded here https://devzone.nordicsemi.com/f/nordic-q-a/79351/libuarte-connection-between-nrf9160dk-and-nrf52840/330790#330790 instead.

RE: libuarte: Connection between NRF9160dk and NRF52840

Brett — Tue, 07 Sep 2021 20:21:57 GMT

Hi Vidar,

No difference. It still works in debug mode but fails otherwise.

-brett

RE: libuarte: Connection between NRF9160dk and NRF52840

Vidar Berg — Tue, 07 Sep 2021 16:58:22 GMT

Hi Brett,

On the 52840 side, could you try to call sd_clock_hfclk_request() after enabling the Softdevice? This will make the Softdevice keep the HF crystal oscillator (HFXO) on and in turn increase the accuracy of the UART baudrate generator (it runs off the less accurate HFINT clock by default). I think it's worth trying since you seem to get more stable performance when you keep the chip in debug mode.

I will try to see if I can replicate it here if the above doesn't help.

Best regards,

Vidar