using rawSerial adds about 600µA

[RobVlaar]

Description

• type: bug

---

Bug

Target
NRF52840

Files
serial_api

mbed-os
5.12.0

Issue
The total power consumption of our board is about 20 µA in low power mode without a serial interface. When we try to use rawSerial to communicate to a chip on our board the total power consumption jumps to 620 µA. the current consumption is also this high even without communicating. When we make a new rawSerial object and later destruct it, the power consuption stays 620 µA no matter which pins we configure.
When we make our own UART via the nrf_uart.h lib, it is possible to communicatie via UART and then disable it again and the power consumption drops to 20µA again.
With the rawSerial we have already tried stop the UART and disable it but this didnt help.

It seems like the chip is going into deep sleep mode and we have already tried to stop the hfxo but this doesnt seem to be the problem. We have also checked al the pins i use to see if one is configured wrong but this also doesn't seem to be the problem. We can't find annything strange in the init function of the serial_api so we hope someone over here knows whats going on.

Question
Does annyone know why constructing a rawSerial use so much extra current ?

[0xc0170]

SerialBase ctor:

    serial_init(&_serial, tx, rx);
    serial_baud(&_serial, _baud);
    serial_irq_handler(&_serial, SerialBase::_irq_handler, (uint32_t)this);

I assume one of these results in higher current as they initialize serial peripheral. What happens if an object is destroyed ?

One workaround (the real fix needs to still be implemented) would be to invoke serial_free in SerialBase destructor - it's currently not there yet, we have one PR opened and should get in soon.

[0xc0170]

This is the fix, you can test it: #10924

[RobVlaar]

@0xc0170 thanks for your reply,
the current jumps to 620 µA with the serial_init.
When an object is destroyed nothing happens, the current consumption stays high
I have tried the fix on 10924, but this doesn't do the trick either.
I already have tried using the serial_free, but this doesn't change annything.
I've noticed that the current jumps to 620 µA after nrf_uarte_task_trigger(nordic_nrf5_uart_register[instance], NRF_UARTE_TASK_STARTRX); on line 803 in serial_api.c is called.
But when i try to stop it with NRF_UARTE_TASK_STOPRX, nothing happens and the current consumption stays high.

[ciarmcom]

Internal Jira reference: https://jira.arm.com/browse/MBOTRIAGE-2286

[0xc0170]

Thanks for getting back. I dont see in free implementation stopping the task, should it be added ? If yes, please send a PR fixing it.

Check this https://devzone.nordicsemi.com/f/nordic-q-a/53121/uart-low-power-shutdown-issue . If our serial_free is not sufficient to decrease the power, we must be missing some deinit or there might be a driver issue. Although this reference might not fix this, might point us the right direction.

My first question would be: what nrfx_uarte_uninit does that we don't ? The only function used in our free implementation is nrf_uarte_disable. What about returning pins to default state, and others covered in this uninit function?

[RobVlaar]

@0xc0170 i have tried the workaround in the link, by turing the peripheral off and on again. And this does the trick.
I have also tried to use the nrfx_uarte_uninit with the new nrf SDK but this didn't change annything.
i have now added

*(volatile uint32_t *)0x40002FFC = 0;
*(volatile uint32_t *)0x40002FFC;
*(volatile uint32_t *)0x40002FFC = 1;

to the serial_free which i have added to the destructor of SerialBase

This clears all the registers in the UARTE0 so i have to construct a new rawserial each time i need it.
It is far from ideal but for now it is a good fix for me.

Thanks for the help

[0xc0170]

@0xc0170 i have tried the workaround in the link, by turing the peripheral off and on again. And this does the trick.

Would you be able to send a pull request fixing this ? serial_free for nrf52

cc @desmond-blue

[desmond-blue]

Hi @RobVlaar , per uart-low-power-shutdown-issue mentioned by Martin, there is an official fix of this driver bug, would you apply this fix instead of the workaround?