TWI_MASTER_HW (PPI) w/ and w/o SoftDevice Enabled

Question

I have an application in which I would like to be able to enable and disable the SoftDevice. 
 But there are peripherals (Application Timers, Two Wire Interface, etc) that I would like to setup and remain operational through the SoftDevice transitions. 
 Is this possible - and if so - should I enable the SoftDevice at startup - then use the sd_ API calls to setup peripherals (PPI for instance inside the TWI_MASTER) ??? 
 Just want to make sure that then when I disable the SoftDevice - that what I've configured using the API calls remains configured. As the SoftDevice SVCALL documentation has me concerned (bold below). 
 /**@brief Disables the SoftDevice and by extension the protocol stack.
* 
 
 Idempotent function to disable the SoftDevice. 
 
 @post SoC library and protocol stack APIs are made unavailable. 
 @post All interrupts that was protected by the SoftDevice will be disabled and initialized to priority 0 (highest).
*** @post All peripherals used by the SoftDevice will be reset to default values.** 
 @post All of RAM become available. 
 @post All interrupts are forwarded to the application. 
 @post LFCLK source chosen in ::sd_softdevice_enable will be left running. 
 
 @return ::NRF_SUCCESS
*/
uint32_t SVCALL(SD_NRF_SOFTDEVICE_DISABLE) sd_softdevice_disable(void); 
 
 Thanks !
-Tim

Ole Morten · Accepted Answer

As the last bullet says, the softdevice will keep the LFCLK running, even when you disable the softdevice itself, so there shouldn't be any concerns with app_timer. Also, any PPI channels that have been enabled will stay enabled and similar, the comment concerns only the peripheral blocks used by the softdevice itself. 
 There is currently no way to manipulate PPI channels in a way that is independent of whether the softdevice is currently enabled or not. If you try to call the sd_ppi_* functions when the softdevice is disabled, you should get the NRF_ERROR_SOFTDEVICE_NOT_ENABLED error back. You could therefore consider using this error to know if it's safe to just write directly to the registers. 
 Also, for completeness: If you target the second revision chip (which you should) you can also consider just removing the PPI use from the TWI module. The use of the PPI was a workaround for issue 36 in the PAN , and this has been fixed on all second revision chips. Instead of using the PPI, you should be able to just use the SHORTS directly. The only reason it hasn't yet been fixed in the SDK is due to backwards compatibility. 
 Edit: Please take a look at this example to see how SHORTS can be used.