Hi Dialog,
I am attempting to use the DA1468x device as an I2C Slave device using the i2c adapters (ad_i2c_start_slave). For the most part it works but sometimes it doesn't.
The communication protocol is (more or less) as follows:
- wait for message header
ad_i2c_start_slave(ack, sizeof ack , msgHeader, sizeof msgHeader, callbacks, OS_EVENT_FOREVER);
... wait for data_sent and data_received callbacks
- wait for payload
ad_i2c_start_slave(ack, sizeof ack, msgPayload, sizeof msgPayload, callbacks, TIMEOUT);
- process and get result ready
ad_i2c_start_slave(ack, sizeof ack , waiting_for_result, sizeof waiting_for_result, callbacks, TIMEOUT);
- send result
ad_i2c_start_slave(ack, sizeof ack , result, sizeof result, callbacks, TIMEOUT);
The ad_i2c_start_slave() can generate 4 different callbacks depending on whether read and/or write buffers are provided. From my experience I am not able to properly handle the read request callback so I opted for always providing wbuf and rbuf for ad_i2c_start_slave() so that I am only concerned about data_sent and data_received callbacks.
So at every stage (above) it is expected that the i2c master sends data and reads data (say an acknowledgement). So basically I am waiting for data_sent and data_received events to be triggered in order to advance to the next stage of the protocol (see above).
However sometimes they i2c bus hangs (SCLK is held low). I am guessing this is because data is requested (or data sent to) which is not handled by the software. How can this happen? I think this can occur when during the switches of the buffer between each stage. However shouldn't the old buffers be used instead? or are these buffers used only one time?
Another issue that can occur I'm guess is that there's pending transactions that I do not know how to cancel in the case of timesouts. See my other post here : https://support.dialog-semiconductor.com/forums/post/dialog-smartbond-bl...
So my question is how can use the ad_i2c_start_slave() with timeouts the way how described in the protocol mentioned above and or do you have any suggestions on how I can implement this.
PS. The issue I was having before with read_request callback is that reading the data from the buffer didn't really stop the interrupt (RX_FULL) from continuously being triggered. Perhaps if you have suggestions how this can be done in combination with the protocol I'll be more than welcomed to hear it.
JLINK Adapter - It appears that the minimal pins used for the DA14580 is SWCLK, SWDIO, Reset, Vcc, Gnd. Is there an adapter that takes me down to the minimal number of pins? I checked on this page: https://www.segger.com/jlink-adapters.html. It looks like the J-Link 9-pin Cortex-M Adapter, would work with the following assumptions:
1) Vtref gets tied to 3.3V. On a diagram for another adapter, Vtref is simply left unconnected in a schematic they provide, so not certain which is the case.
2) SWTDIO connected
3) SWCLK connected
4) SWO unconnected
5) TDI unconnected
6) nReset - since Rset on the DA14580 is active high, I assume that I need to provide an inverter on the board to handle this
7) Pins 7 and 9 unconnected
8) Pins 3 & 5 get tied to ground.