TWI with Softdevice S110

[Darshan]

Hi

I have a problem using TWI driver with my softdevice enabled.

The TWI is able to communicate successfully to the slave without the softdevice.

But the same code when merged with the softdevice and an character sent for Read/Write returns busy or the BLE chip restarts.

Below is the part of example code used for toggling led ON/OFF by sending an character from phone.

Find full code here = BLE_TWI.txt

Please tell me what changes I should make.

[Wojtek]

Blocking delay (ex. nrf_delay_ms(500) 500ms! ) is definitely not something you should use while using softdevice.

[RK]

well there's nothing wrong with it per-se, it won't break anything, it just won't give an accurate 500ms. The softdevice interrupts will continue to happen and interrupt the nrf_delay, which is just a busy load of NOPs making it a random delay which is something longer than 500ms. It's not clear from a cursory look at that code whether accurate delays even matter.

oh one point I should have made - if you do long blocking delays during an interrupt handler at APP HIGH priority - that is bad as it will stop the softdevice executing its lower priority tasks, but blocking in interrupt handlers anyway is a bad idea and you can actually block in the APP LOW priority ones if you want to without bothering the softdevice at all. Not that I recommend it.

[Darshan]

I reduced the delay to 5ms for both Read/Write still its not working.

Which Driver should I be using for TWI with soft device ?

[Darshan]

Thank you I sorted out the problem

the problem was with twi Initialization p_twi_config.interrupt_priority = APP_IRQ_PRIORITY_LOW;

after I changed it to p_twi_config.interrupt_priority = APP_IRQ_PRIORITY_HIGH;

its working now both Read/Write.

[RK]

That's exactly the one case I mentioned above that you should not do, use nrf_delays in any interrupt handler which is running in APP HIGH priority - so if you're doing that, you'll eventually mess up your bluetooth connection.

Not that I know why you were putting delays in all over the place, none of them are necessary and if you're doing that, you're just working around issues in your code.

write data, get callback, read data, get callback, no delays needed.