What exactly do nrf_drv_twi_disable() and _enable() do?

[Ladasky]

I am working with a sensor which has a programmable configuration register. After changing this register, I have to reboot the sensor. To do this, I need to temporarily suspend a TWI master driver and manipulate the SCL and SDA GPIO lines directly, as described in this earlier discussion:

devzone.nordicsemi.com/.../

Looking through the Nordic documentation, I'm trying to figure out how to get this done.

In the SDK docs I have found the functions nrf_drv_twi_disable() and nrf_drv_twi_enable(). These functions are sparsely documented. Nor are these functions used in any of the software examples. What exactly do they do?

In the hardware docs (Section 47) I found references to the registers PSELSCL and PSELSDA. These registers determine the pins that are driven by the TWI. I found these elements within the NRF_TWI_Type data structure, and I can read their values. The documentation says I can only WRITE these registers when the TWI is disabled.

I started with a pretty simple modification to an existing program; just adding calls to nrf_drv_twi_disable() and nrf_drv_twi_enable() after some data transfers have completed, with short delays in between each call (0.5 seconds each). I haven't tried to modify PSELSCL or PSELSDA yet, or to write to the GPIO lines. Still, this simple change crashes. APP_ERROR_CHECK fails, my program reboots, and then the first new thing that my program tries to do on the TWI (just reading a register) causes another APP_ERROR_CHECK failure.

I don't know that any of this is Nordic's fault, since the slave device is obviously a little strange. But the failure is profound. When my system gets into an error state, I can only solve the problem by completely unplugging everything. I have to turn off my nRF52 board, and disconnect it from USB. I even have to unplug my slave device from the Nordic board (which is also its power source).

After I reboot, provided that a working program is in flash, everything functions again. By "working program" I mean that one which changes the configuration register, but doesn't (yet) perform the sleep-and-wake cycle that I want.

I am using a the nRF52 Preview board and SDK 0.9.2 (the highest revision that I can use).

Thanks for any help you can provide!

[RK]

UART debugging is like trying to drive a bus with your nose. The preview board has a whole segger debugger on it which can print things out, breakpoint the code .. you're making life way harder for yourself not using it. Even RTT is a better way of outputting data than UART, it doesn't need flushing, it doesn't take any time to be transmitted. Yes once you break with the softdevice running you can't resume, but it's way better than using the UART.

All you would then have to do is put a breakpoint on the line(s) which return that error, run your code, and when it breaks you inspect the state, which should tell you why it failed.

There's lots of places seem to return that error code but it shouldn't be that hard to work out which one of them it was.