Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

using rawSerial adds about 600µA #11758

Closed
RobVlaar opened this issue Oct 28, 2019 · 8 comments · Fixed by #11790
Closed

using rawSerial adds about 600µA #11758

RobVlaar opened this issue Oct 28, 2019 · 8 comments · Fixed by #11790

Comments

@RobVlaar
Copy link

@RobVlaar RobVlaar commented Oct 28, 2019

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

This comment has been minimized.

Copy link
Member

@0xc0170 0xc0170 commented Oct 28, 2019

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 comment has been minimized.

Copy link
Member

@0xc0170 0xc0170 commented Oct 28, 2019

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

@RobVlaar

This comment has been minimized.

Copy link
Author

@RobVlaar RobVlaar commented Oct 28, 2019

@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

This comment has been minimized.

Copy link
Member

@ciarmcom ciarmcom commented Oct 28, 2019

@0xc0170

This comment has been minimized.

Copy link
Member

@0xc0170 0xc0170 commented Oct 29, 2019

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

This comment has been minimized.

Copy link
Author

@RobVlaar RobVlaar commented Oct 30, 2019

@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

This comment has been minimized.

Copy link
Member

@0xc0170 0xc0170 commented Oct 30, 2019

@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

This comment has been minimized.

Copy link
Contributor

@desmond-blue desmond-blue commented Oct 31, 2019

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.