Different power consumption DEVKIT module vs SOC

⚠️
Hi there.. thanks for coming to the forums. Exciting news! we’re now in the process of moving to our new forum platform that will offer better functionality and is contained within the main Dialog website. All posts and accounts have been migrated. We’re now accepting traffic on the new forum only - please POST any new threads at https://www.dialog-semiconductor.com/support . We’ll be fixing bugs / optimising the searching and tagging over the coming days.
7 posts / 0 new
Last post
essele
Offline
Last seen: 1 year 8 months ago
Joined: 2020-12-19 15:33
Different power consumption DEVKIT module vs SOC

Hi,

I'm just getting started with a few examples using the DA14531DEVKIT-PRO and I have two daughterboards, the normal SoC one and the module based one.

Using just the barebone ble example with ARCH_EXT_SLEEP_ON, on the SOC version I see a current consumption (on average) of about 1.6uA, yet on the module based one I see just over 10uA (measured using a multimeter connected to J9)

I am assuming that this is because of te flash not being properly disabled as per the following:

https://support.dialog-semiconductor.com/forums/post/dialog-smartbond-bl...–-software/power-down-da14531mods-spi-flash

However ... I have SPI_FLASH disabled... (#undef CFG_SPI_FLASH_ENABLE) .. and even if I enable it, there doesn't seem to be any difference.

I have tried putting an spi_flash_powerdown() in user_app_init(), however that clearly isn't going to work if flash isn't enabled, and it also doesn't work if it is ... in both cases I get a 300uA consumption and no advertising, so I'm assuming it's hanging (haven't tried debugging it yet.)

Is there something I'm missing ... the poster in the other post seemed to figure it out, but I can't see anything in the hibernation example that makes sense.

Many thanks,

Lee.

 

Device: 
MHv_Dialog
Offline
Last seen: 1 year 2 months ago
Staff
Joined: 2013-12-06 15:10
Hi Lee,

Hi Lee,

All of your observations are valid. The issue is that the flash device in the module is consuming excessive power due to the state of the slave select pin (Aka chip select, spi enable, etc.). To reduce this power consumption, all you have to do is to ensure that the SS pin is kept high at every wakeup. This is managed in the function set_pad_functions() of user_periph_setup.c. For our DA14586, you can see this (SDK sample project empty_peripheral_template for instance):

#if defined (__DA14586__)
    // Disallow spontaneous DA14586 SPI Flash wake-up
    GPIO_ConfigurePin(GPIO_PORT_2, GPIO_PIN_3, OUTPUT, PID_GPIO, true);
#endif

For the DA14531 module, it should look like this:

#if defined (__DA14531__)
    // Disallow spontaneous DA14531 SPI Flash wake-up
    GPIO_ConfigurePin(GPIO_PORT_0, GPIO_PIN_1, OUTPUT, PID_GPIO, true);
#endif 

The differnce between the module and the SoC should then drop to about 300nA.

/MHv

essele
Offline
Last seen: 1 year 8 months ago
Joined: 2020-12-19 15:33
Hi,

Hi,

Thanks for the answer, however I don't think it's quite right ... the code already has this ...

#if defined (__DA14586__)
    // Disallow spontaneous DA14586 SPI Flash wake-up
    GPIO_ConfigurePin(GPIO_PORT_2, GPIO_PIN_3, OUTPUT, PID_GPIO, true);
#else
    // Disallow spontaneous SPI Flash wake-up
    GPIO_ConfigurePin(SPI_EN_PORT, SPI_EN_PIN, OUTPUT, PID_SPI_EN, true);
#endif

... which I think achieves the same as you suggest.

I've tried adjusting this to your specific code and it made no difference.

... I haven't read the specific datasheet for the flash, but most of them start up in non-power-saving mode don't they? So I assume you actually need to enable the flash, and then put it in power saving mode?? Or have I missed something?

Lee.

MHv_Dialog
Offline
Last seen: 1 year 2 months ago
Staff
Joined: 2013-12-06 15:10
Your code is identical to

Your code is identical to mine except that my code directly specifies the pin.

I thought you mentioned that you had already tried to enable the flash and then put it to sleep, did I misunderstand something? 

/MHv

MHv_Dialog
Offline
Last seen: 1 year 2 months ago
Staff
Joined: 2013-12-06 15:10
Hi Lee,

Hi Lee,

I think that your application is probably hanging - on my module forcing a hang leads to about 250uA.

Try to start with the empty_peripheral_template project and set the sleep mode to extended sleep. Load this on the module via JTAG from Keil (attach then detach the debugger) to run the code and measure the power consumption. Do the same thing on the SoC and you should see a huge difference in power consumption (on my board it is about 1mA). Then add the hardware configuration of SPI SS as described above and repeat the measuremnent on the module. The current consumption on the SoC and the module will be almost identical.

/MHv

essele
Offline
Last seen: 1 year 8 months ago
Joined: 2020-12-19 15:33
Hi,

Hi,

This is now solved ... it wasn't as you suggested, it was actually my complete lack of understanding of how things were initialised. I had assumed that enabling CFG_SPI_FLASH_ENABLE would be enough to properly enable the flash, but this absolutely isn't the case.

For reference, the datasheet for the module flash (P25Q11U) clearly shows a 9uA standby current and a 0.1uA deep power down current, so pretty much a 9uA difference, which is exactly what I was seeing. Also, the module will power on in standby mode and needs to be specifically put in deep power down mode.

The primary issue with the code example I am using (ble_app_barebone) is that none of the SPI or flash initialisation code is actually in there, so the CFG_SPI_FLASH_ENABLE doesn't actually do anything, and therefore a call to spi_flash_powerdown() won't work.

A bit of further investigation into the hibernation example (as referenced in the other post that I linked in the question) and you can find all of the required code to initialise the pins, initialise SPI, and then a call to spi_flash_powerdown() in user_app_init() and everything works perfectly ... I'm actually seeing slightly less power consumption, at around 1.4uA ... but this is just with a multimeter, so may be missing peaks etc.

So this is great ... thanks.

essele
Offline
Last seen: 1 year 8 months ago
Joined: 2020-12-19 15:33
Further ... I've just found

Further ... I've just found this that explains it all perfectly ...

http://lpccs-docs.dialog-semiconductor.com/da145xx_tutorial_sdk6_periphe...