Cutting power to nrf51 after receiving spi bytes and advertising them using BLE

RE: Cutting power to nrf51 after receiving spi bytes and advertising them using BLE

Karl Ylvisaker — Wed, 14 Jul 2021 16:09:58 GMT

Hello again,

Thank you for your patience with this. The summer holidays have begun here in Norway, and DevZone is therefore operating with reduced staff for the time being. Sorry for any inconvenience this might cause.

[quote user="aalsubhi"]Thank for you informative and fast response.[/quote]

No problem at all, I am happy to help!

[quote user="aalsubhi"]It works fine by setting the advertisement interval to 100ms and make the MSP430 (master) wait more than 100ms (about 300ms-500ms) before cutting the power on nrf51 (slave).[/quote]

Do I understand this correctly that you went for a merge of the two approaches - having the nRF51 enter sleep mode on its own following completed advertising, and then cutting its power afterwards? If so, could you elaborate why you still opt to cut its power? I am interpreting 'cutting its power' literally, i.e that you toggle a transistor on its power supply lines, or similar. Do I have this correctly?
I would think that you could achieve lower power consumption by doing either of the things, like suggested in my previous comment.
Did you try the two approaches separately, to compare their power consumption?

[quote user="aalsubhi"]I solved this problem. I used SPI mode 0 (CPOL = 0, CPHA = 0) on nrf51 and (CPOL=0 CPHA=1) on msp430. Also, I have to wait at least 3ms after turning the nrf51's power on before sending any data through spi.[/quote]

I am glad to hear that you were able to resolve this new issue! These 3 ms of wakeup cycles is what I was referring to as potentially negatable through keeping the device in SYSTEM ON sleep between advertisements.

Best regards,
Karl

RE: Cutting power to nrf51 after receiving spi bytes and advertising them using BLE

aalsubhi — Mon, 12 Jul 2021 23:13:48 GMT

I solved this problem. I used SPI mode 0 (CPOL = 0, CPHA = 0) on nrf51 and (CPOL=0 CPHA=1) on msp430. Also, I have to wait at least 3ms after turning the nrf51's power on before sending any data through spi.

RE: Cutting power to nrf51 after receiving spi bytes and advertising them using BLE

aalsubhi — Sun, 11 Jul 2021 19:29:27 GMT

Here is the current consumption of nrf51 when spis and BLE broadcast are used:

Here is the current consumption when I don't use spis and only use BLE advertisement:

You can see when SPIS is used nrf51 consumes around half mA even when the it is power off by the master (MSP430).

RE: Cutting power to nrf51 after receiving spi bytes and advertising them using BLE

aalsubhi — Sat, 10 Jul 2021 02:01:29 GMT

Thank for you informative and fast response. I did some experiments to see if turning on nrf51 to send an advertisement then turn it off would work. It works fine by setting the advertisement interval to 100ms and make the MSP430 (master) wait more than 100ms (about 300ms-500ms) before cutting the power on nrf51 (slave).

The problem I faced if I enable spis on nrf51 and try to send some data, uninitiate spis to save power, advertise the received data and then cut the power off, that nrf51 VCC is hinging at 1.5V after cutting the power although the spin and advertisement process are working fine, but this behavior (nrf51 is stuck at 1.4V) is causing a half amp current consumption which is very high for my system.

On the other hand, If I don't use spis on nrf51 and just let the BLE advertise fixed data, every 2s when master (MSP430) powering on nrf51, wait 300ms-500ms then cut power on nrf51, the nrf51 vcc goes low near Zero volt when the power is cut off and there is no high power consumption.

Here is my code :

int main(void)
{   
    // Enable the constant latency sub power mode to minimize the time it takes
    // for the SPIS peripheral to become active after the CSN line is asserted
    // (when the CPU is in sleep mode).
    NRF_POWER->TASKS_CONSTLAT = 1;

    memset(m_tx_buf, 0, BUF_SIZE); // initializing  the TX buffer

    APP_ERROR_CHECK(spi_peripheral_init()); // Initialize SPI to receive sensor data from MSP430

    memset(m_tx_buf, 0, BUF_SIZE); // initializing  the TX buffer

    memset(m_rx_buf, 0, BUF_SIZE); // reset the RX buffer
    receiving_completed = false;

//    //Set buffers.
    APP_ERROR_CHECK(nrf_drv_spis_buffers_set(&m_spis, m_tx_buf, sizeof(m_tx_buf), m_rx_buf, sizeof(m_rx_buf)));
//
    while(!receiving_completed) // Wait for data from the Central (MSP430)
    {
        __WFE();   //stay in low power mode
    }
    nrf_drv_spis_uninit(&m_spis); // uninit spis to save power

    // Initialize BLE
    ble_stack_init();
    advertising_init();

    // Start execution.
    advertising_start();
    
    // Main loop.
    while(1)
    {
        
        power_manage();
    }
    
    
}

Do you have any idea why using spis preventing nrf51 vcc to shutdown completely (stuck at 1.4V) when the power is off leading to a half Amp consumption?

RE: Cutting power to nrf51 after receiving spi bytes and advertising them using BLE

Karl Ylvisaker — Fri, 09 Jul 2021 17:35:13 GMT

Hello,

[quote user=""]Every 2s MSP430 derives a pin high to drive the nrf51's VCC high and send multiple bytes. nrf51 after receiving the bytes through spi , tries to advertise them. Then MSP430 waits 200 ms(after sending the multiple bytes) before cutting the nrf51 power off.[/quote][quote user=""]Is there any way to cut the power safely on nrf51 while insuring the advertisement packet at least advertised once ? [/quote]

I would propose that you instead implement the nRF51 to go into SYSTEM_ON sleep mode whenever it finishes the advertisement. This way, you would know for certain that the advertisement has completed successfully, while avoiding spending time every 2 s to setup and configure the device.
You could make use of the Radio Notification to know that a radio event has completed. If you are only doing advertising, this will be the only type of event occurring.

As long as you uninitialize your peripherals and release the clocks when you are done with them, the average power consumption while in SYSTEM_ON sleep is quite low. This, combined with the time the device will have to spend every 2s in order to wake up and get ready leads me to believe that the SYSTEM_ON sleep option would give you a lower average current consumption and easier time implementing and controlling it.
This will also reduce the time it takes to wake-up and configure the device to make it ready to receive the SPI transfer, and setup and configure the SoftDevice.

Alternatively, for the lowest possible baseline current draw between transfers you could have the nRF51 go into SYSTEM_OFF sleep, and then waking it every so often through the pin interrupt - the important point here is that it should go to sleep on its own, whenever it is finished sending an advertisement, for example.

If you want to cut the power to the NRF51 completely between transfers, you could have it toggle a pin to communicate that it has completed an advertising, and then cut the power.

Please keep in mind that it is not guaranteed that an advertising packet will be received successfully by a central. The packet may be lost, corrupted or simply 'not read' (if the central is not scanning at the particular time of the advertising).
Advertisements have no acknowledgement, so the sender will never know if the advertisement successfully arrived at the central. However, a BLE connection is lossless, so any packets that are not acknowledged will be resent in the next connection event. If no packets are acknowledged, the link is terminated.

If it is important that you do not potentially loose the data in the advertising packets I would suggest that you instead enter into a connection with a very long connection interval. If the device is in SYSTEM_ON sleep it will be ready to wake up whenever an event is generated (such as a reception on the SPI peripheral (if enabled), or an upcoming radio event).

Best regards,
Karl