SPI Always consume about 1 mA on ble

RE: SPI Always consume about 1 mA on ble

Edvin — Wed, 09 Jan 2019 10:29:57 GMT

For wakeup times, please refer to this site:
http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52832.ps.v1.1%2Fpower.html&cp=2_1_0_17_9_1&anchor=unique_744469603

Regarding your current consumption, how did you run your power_manager()? Can I see the bottom of your main() function? Does it go directly into nrf_pwr_mgmt_run() in a for (;;) loop in your main?

How did you set up your timers? The timers also draw a bit of current, depending on what sort of timer it is.

BR,

Edvin

RE: SPI Always consume about 1 mA on ble

Kaito — Wed, 09 Jan 2019 09:11:29 GMT

thank you for your reply!

I was able to lower it to 400 μA as a result of taking the average consumed current several times using timer interrupt and power_manager (). But constantly

However, we constantly consume about 200 μA of current. Is there any good plan as a way to lower this current consumption?

what is the rise time from system off mode? Also, is there anything that shows the rise time from system off mode?

best regards!!

RE: SPI Always consume about 1 mA on ble

Edvin — Wed, 02 Jan 2019 08:43:06 GMT

Yes. It is possible to put the nRF in deep sleep to save some power. Note that this is like turning the chip off, and it will start from the top of your main() function when it wakes up. Also, to wake it up, you need an external interrupt. That is either by a pin interrupt, power on cycle, or an NFC interrupt. You can't have any timers running while in deep sleep, so you can't wake up on a timer interrupt.

It does take some time to wake up from deep sleep, and you have to enable the peripherals, so if you are transmitting every 8ms, I don't think this would be beneficial.

If you want to lower your current consumption, you should use the power_manage() function that is used in the ble_app_uart example to make the device go to "not deep" sleep. Then you can wait for timer timeout events.

Best regards,

Edvin

RE: SPI Always consume about 1 mA on ble

Kaito — Tue, 25 Dec 2018 04:40:31 GMT

Hi!

For low power consumption, I am considering putting it in deep sleep mode when data transmission is not done by SPI communication.

However, the data transmission interval is as short as 8 milliseconds, during which deep sleep mode is entered. I want to wake up before sending the data and send the next data

How long will it take to enter deep sleep mode and get up?

Is it possible to reduce power consumption considerably by putting it in deep sleep mode?

best regards!!!

RE: SPI Always consume about 1 mA on ble

Kaito — Tue, 25 Dec 2018 04:23:34 GMT

thank you for your reply!

sorry,I wanted to ask if UART should be stopped :(

I put a function to stop the UART before the main loop.

Even though I do not use UART, UART was enabled.

In that case, I was able to lower the average current consumption to about 350 μA.

thank you for your advice!!

RE: SPI Always consume about 1 mA on ble

Edvin — Fri, 21 Dec 2018 10:57:46 GMT

[quote user=""]Should UART be overcome for low power consumption?[/quote]

What do you mean with this?

[quote user=""]However, data transmission was not completed.[/quote]

So does the application stop there? Does it continue? Do you receive the SPI data on the other side of the link? Do you receive parts of it?

Can you check the return values of nrf_drv_spi_transfer()?

err_code = nrf_drv_spi_transfer();
APP_ERROR_CHECK(err_code);

This also applies when you initialize the SPI.

The SPI shouldn't consume this amount of current.

How do you measure the current consumption?

Can you try to disable the SPI (not initialize it at all, and don't use it), does the current consumption go down then? Or could it be something else drawing power? Does your application go to sleep?

I also see that you use a lot of nrf_delay_us(). This is not really lucky when you are using the softdevice. It can cause asserts if the softdevice misses a time critical event. This could also be the cause of your "data transmission was not completed" issue.

My main suggestion is to check the return values of the functions that return, such as your spi functions. Also, if the application "stops working", "crashes", "freezes", or "stops advertising", please define DEBUG in your preprocessor definitions, and watch the log. It is probably an APP_ERROR_CHECK() catching an err_code != NRF_SUCCESS.

Best regards,

Edvin