This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

TWI is not working with SoftDevice

This seems to be a common problem after searching in this forum. In my case, I need to read from an I2C slave and send the data out in BLE. I have made it work without SoftDevice using this library code http://pastebin.com/qLLAy418 . However, it failed to work with SoftDevice. I also tried with another version which has SoftDevice knobs http://pastebin.com/AV6cQK0x. It doesn't work either. I also tried other code github.com/.../twi_hw_master.c that someone claimed to work (devzone.nordicsemi.com/.../), but it doesn't work for me. Can anyone provide any suggestion on this problem?

Parents
  • What does 'doesn't work' mean? Crashes, sends erratically, goes to the hardfault handler, the board bursts into flames, what?

    The TWI handler in the library works with the softdevice quite happily, as it should, they are entirely separate things.

    So what exactly happens when you use the nordic TWI driver from the SDK for your board with and without the softdevice?

  • well I wouldn't use the sw one with the softdevice, use the hw one. And if it's returning false, why is it returning false? Is it timing out (timeout --> 0 ) or returning an error?

    I see by the way that twi_hw driver STILL uses the PPI channel to trigger the STOP or SUSPEND task from the BB event. If you have any hardware newer than revision 1 you can change that to use the TWI SHORTS instead, that old PPI hack was just because SHORTS didn't work on the first revision. I wish they'd update that.

    The only possible difference between having a softdevice and not is that the TWI hardware might be suspended for longer before the byte is read and the TWI continues. That shouldn't matter, it just stretches the clock so the master you're reading from should wait before sending the next byte. Does the TWI device you're reading from support clock stretching, it should, it's part of the spec.

Reply
  • well I wouldn't use the sw one with the softdevice, use the hw one. And if it's returning false, why is it returning false? Is it timing out (timeout --> 0 ) or returning an error?

    I see by the way that twi_hw driver STILL uses the PPI channel to trigger the STOP or SUSPEND task from the BB event. If you have any hardware newer than revision 1 you can change that to use the TWI SHORTS instead, that old PPI hack was just because SHORTS didn't work on the first revision. I wish they'd update that.

    The only possible difference between having a softdevice and not is that the TWI hardware might be suspended for longer before the byte is read and the TWI continues. That shouldn't matter, it just stretches the clock so the master you're reading from should wait before sending the next byte. Does the TWI device you're reading from support clock stretching, it should, it's part of the spec.

Children
No Data
Related