Powering down the DA14580 SoC et al can be a useful tool for achieving minimum power consumption when Bluetooth connectivity is infrequent, and this is done typically with a LDO regulator or sufficiently strong host I/O port pin. However, care is required to ensure no port pins are driving into the SoC during that power-down period. In a simple system typically a UART Rx, Tx and the BLE SoC RST pins will be connected between host cpu and SoC. In that simple case either Rx or Reset pins will phantom power the entire DA1458x BLE device if they are left driven high while BLE SoC power is removed when turning off the LDO. This is perhaps not unexpected if we assume dual internal schottky diode protection (a clamp diode to both GND and VCC) instead of single internal schottky diode (to GND with low breakdown voltage). This means that to power-down the BLE SoC the MCU code must first drive both UART RX and BLE RST pins low, otherwise the supply of (say) 3 volts only drops to 2 volts or so when the LDO is switched off and the SoC therefore does not reset.
In a similar manner, connecting a typical FTDI USB serial port to the SoC can unexpectedly phantom power the part, and stop it correctly resetting or powering down unless the FTDI is first removed. This can cause confusing and unexpected behavior. There is an excellent Dialog publicationTraining_07_DA1458x_prototype_bring_up_guide-v1.2Iwhich actually touches on this without mentioning why:
It is recommended that P0_4 and P0_5 are made available for UART communication during production test and board bring-up. Note that, if the two pins are also used as interface to an external MCU, that this MCU will need to be able to high-Z the pin connected to P0_5.
The reason is that resetting the test board doesn't work correctly unless drive to the Rx pin is first removed, including drive from any connected FTDI USB serial port.
嗨nzbackpackers,
Yes you are correct, what you are mentioning is a known issue on the 580, the UART can indeed power enough the chip and prevent a Power On Reset, and thats why you will have to pull down the lines in order to have a proper RESET.
Thanks MT_dialog