nRF52840 UART queries

RE: nRF52840 UART queries

beemavishnu — Sat, 21 Dec 2019 14:43:52 GMT

Thanks a lot for your inputs and doing actual current measurements.

RE: nRF52840 UART queries

Håkon — Thu, 19 Dec 2019 15:31:22 GMT

Hi,

1) UART is only enabled when the bootloader enters DFU mode, e.g. when the button is pressed

2) When DFU is completed the device resets, and if no button is pressed after the reset, the bootloader validates the application, then starts the application.

I did some quick measurements with the power profiler kit on the nRF52840.
I modified the peripheral -> serial example to either enable uart, then enter sleep mode, or disable uart before entering sleep mode.

In the attached pictures below you can see that the UART being enabled adds around 600 uA.
With UART enabled ~630 uA
With UART disabled ~18 uA

Code changes:
Add the following lines before the infinite loop in the example.

//nrf_drv_uart_uninit(&serial_uart); // comment out to disable UART peripheral
while(true)
{
    sleep_handler(); // Enter sleep mode
}

RE: nRF52840 UART queries

beemavishnu — Thu, 19 Dec 2019 09:43:16 GMT

Hi,

I my use case first Secure Serial bootloader is loaded and then my ble_app_blinky with UART application is loaded.

1) Because of Secure serial bootloader whether serial uart is always enabled. Even I am not seeing calling nrfx_uarte_uninit().

2) (Or) Can I assume when pin is pressed then only chip will enter into boot mode and once DFU done, device will reset, so no issue even if there is no initialization of uart.

3) What will be the current with uart enabled. Whether it will be 3 to 4 mA of ideal current. Anyway I will test practically, but this is for my quick understanding.

Thanks & Regards

Vishnu Beema

RE: nRF52840 UART queries

Håkon — Thu, 19 Dec 2019 08:41:53 GMT

Hi,

From your followup questions:
a) The device can enter low power modes regardless of the UART being enabled. Simplistic said low power mode is to halt the CPU and make it wait for an event to happen. The CPU will resume operation when an event occur, handle the event and enter the wait-for-event mode again. However, the UART consumes energy by being enabled. This applies to all peripherals.

b) The CPU will enter low power mode, but the current consumption is higher than needed. This can easily be measured if you run e.g. the app_ble_uart example and do measurements with and without UART enabled.

c) The ble_app_uart example does not handle dynamic enabling and disabling of UART. However, when you know you system's needs you can dynamically turn the UART on and off whenever needed. The function app_uart_close() can be used to disable the UART.

RE: nRF52840 UART queries

beemavishnu — Wed, 18 Dec 2019 06:52:04 GMT

Thank you for your inputs.

1) Yes, I want RTT for debug logs and UART for serial communication with other board.

2) app_uart_put() is working. Issue is with my code. I am increment index before printing. So it will be a null character and I will not be seeing.

My further queries are:

1) Need more inputs on the statement “UART peripheral whenever possible”.

a) Assume BLE is advertising every 1 sec and to my understanding nRF will go to low power mode in-between Advertisement packets. But if UART is always enabled will not nRF chip go to low power mode in-between Advertisement packets.

b) If UART is always enabled, whether controller will not go to low power mode and whether current consumption will be more.

c) In ble_app_uart, how are you handling of enabling and disabling of UART. Is there any reference.

Thanks & Regards

Vishnu Beema

RE: nRF52840 UART queries

Håkon — Tue, 17 Dec 2019 15:19:13 GMT

Hi,
I will try to answer your questions.

1) Yes, you understand correctly. UART0 and UARTE0 share the same memory space and HW and can be used with or without EasyDMA. UARTE1 can only be used with EasyDMA.

2) I don't understand, you say you need UART, but you have enabled RTT? Do you mean that you need our logger, and want to use RTT as the log backend, or do you need the UART to be available as part of the application, while RTT is only for logging? In both cases, it should be OK.

3) app_uart_put() is to be the correct way to transmit data in this context.
If you have a look in the nus_data_handler(ble_nus_evt_t * p_evt) you can see how app_uart_put() is used.
It seems that you are not waiting the tx to finish, other example typically use app_uart_put() inside a while loop. You can se how this is done in e.g. the peripheral example of uart on (line 173).
while (app_uart_put(cr) != NRF_SUCCESS);

4) I understand the confusion, and share this confusion with you. However, the serial port library is only a wrapper around the same functionality as using the uart more directly as is done in the app_uart example. I don't think it matters which method you choose to use, however I find the syntax in the serial port libary to be a bit easier.

a) All the mentioned examples, etc. are able to handle both rx and tx
b) Many of our BLE examples use UART and BLE simultaneously, the app_ble_uart does this as well.
c) I will recommend to disable the UART peripheral whenever possible, and e.g. use a BLE message or a pin input to trigger that the device should start listening on rx.