BLE unreliable when using TWI with NAU7802 ADC chip

RE: BLE unreliable when using TWI with NAU7802 ADC chip

hmolesworth — Tue, 05 Dec 2023 00:10:33 GMT

It is a problem; using those pins for I2C talking rarely to the RTC is rather different from your application ..

RE: BLE unreliable when using TWI with NAU7802 ADC chip

CBrown — Mon, 04 Dec 2023 23:04:48 GMT

I am using PO.26 and PO.27 for my SDA and SCL pins respectively (which are both in that table), but on the BL652 datasheet, these are labeled as I2C_SDA and I2C_SCL pins, so I didn't think that would be a problem.

RE: BLE unreliable when using TWI with NAU7802 ADC chip

CBrown — Mon, 04 Dec 2023 19:58:49 GMT

Hi Karl,

To elaborate:

I am sending ASCII data every 5 milliseconds, at a maximum length of 21 bytes per packet
This is only a rate of 33.6 kbps, and I can see BLE can get to Mbps rates, so I don't think I am reaching the limits of BLE transmission.
Every 5 seconds the data packet gets written to a FIFO (using app_fifo) of length 2048, and whenever I get the BLE_NUS_EVT_TX_RDY event I transmit 244 bytes (the maximum size due to the MTU) from the FIFO using ble_nus_data_send.
When I write to the FIFO I check to see if the FIFO has space. If it doesn't, then I increase an overflow counter and the data packet is dropped.
When I use TWI with the NAU7802 chip, I see the overflow counter increase. This indicates that the FIFO is not emptying fast enough. I assume this is because BLE transmission is slowed (somehow by TWI) so BLE_NUS_EVT_TX_RDY is being called less often.
Note I see this issue only when using TWI.

So the issue is I am missing data packets (not BLE packets), because they are being dropped, because the FIFO does not have enough space, because BLE is slowing down when TWI is being used. I do not want to increase the FIFO size because it will still have the same issue, just take slightly longer to fill up.

Does that make sense? Let me know if you have any ideas.

Kind regards,

Campbell

RE: BLE unreliable when using TWI with NAU7802 ADC chip

Karl Ylvisaker — Mon, 04 Dec 2023 18:54:02 GMT

This is a very good supplement to my comment, thanks hmolesworth ! :)

You should definitely also check that your selected pins are not designated low-frequency in the Pin Assignment.

Best regards,
Karl

RE: BLE unreliable when using TWI with NAU7802 ADC chip

hmolesworth — Mon, 04 Dec 2023 16:40:00 GMT

Worth a mention, just in case you chose the "wrong" pins for TWI SCK:

"20.2 GPIO located near the RADIO
Radio performance parameters, such as sensitivity, may be affected by high frequency digital I/O with large sink/source current close to the radio power supply and antenna pins. Refer to Pin assignments on page 14 for recommended usage guidelines to maximize radio performance in an application."

RE: BLE unreliable when using TWI with NAU7802 ADC chip

Karl Ylvisaker — Mon, 04 Dec 2023 09:36:38 GMT

Hello,

Could you elaborate on what you mean when you say 'missing packets'? Does this mean that you can see that the value is received as expected by the nRF, but then never actually sent to the connected peer? Or does it mean that you expect to read a new sample over the TWI at a given interval, and suddenly miss some of these intervals?

In general, the SoftDevice has the highest priority and will take control over the CPU when a radio event is upcoming in order to reach its timing critical deadlines, which means that it could take control of the CPU right as your CPU is scheduled to execute the TWI read.
If it is critical to your application that this does not happen you could instead look into using the easyDMA feature in combination with the PPI peripheral to trigger TWI transmission without needing the CPU intervention. In most cases you will however be fine just waiting for the radio event to complete and then do another TWI read.

Could you elaborate more on your applications usage and requirements, so that I may better understand your issue and be better suited to advise you on how to proceed?

Best regards,
Karl