CC2340R5-Q1: About I2C Driver for Controller and Target

Hello,

Here is the documentation for the I2C driver: I2C.h File Reference & I2CLPF3.h File Reference more device specific restrictions. I2CTarget.h File Reference contains information regarding target I2C.

Additionally, detailed information can be found in the TRM Chapter 21 Inter-Integrated Circuit (I2C). This has a lot of information regarding the I2C peripheral, especially if you choose not to use our I2C driver.

sjmizuta said:

Q1) Is the level operation of SCL and SDA necessary for bus communication, including ACK/NACK checking and the generation of start/stop conditions in I2C communication, controlled by hardware or software?

The driver should handle this for. However, please pay close attention to the difference between the controller and target drivers. I have linked both above.

sjmizuta said:

Q2) Does it support clock stretching functionality?

Yes.

sjmizuta said:

Q3) What happens when there is a timing conflict with the BLE task?

It is up to the developer to handle this case. It should be noted that the BLE task should have the highest priority.

Best,

Nima Behmanesh

Hi, Nma.

Thank you for your prompt response.

Could you please explain a bit more specifically? Let me rephrase my question.

Q1)We are assuming the use of a driver, so please provide information only for cases where the driver is used.

When using the driver, operations such as start/stop are executed within the API, so is it correct to understand that users can use it without having to interrupt any operations?

Also, since the actions are performed within the API, is it correct to understand that the CC2340R5 is executing these processes through software?

Q2)Thanks.

I believe the content you are addressing pertains to cases where the CC2340R5 is receiving. When the CC2340R5 is transmitting, can the clock-stretching function be used if the transmission data is not ready or if other high-priority processes are being executed?

Is there anything the user needs to do in such situations?

Q3)Please tell me about the operations within the driver.

Since it's confirmed in Q2 that the clock-stretching function can be used, can the driver autonomously use this function to pause I2C communication when a higher priority process conflicts, and then resume I2C communication once the priority process is completed?

I'm sorry for the lengthy message, but I appreciate your cooperation.

Best Regards.

Hello,

I apologize, but I'm a bit confused on what you're asking.

sjmizuta said:

When using the driver, operations such as start/stop are executed within the API, so is it correct to understand that users can use it without having to interrupt any operations?

Yes, the operations such as start/stop are executed within the API, but not sure what you mean by using it without having to interrupt operations. In the documentation I provided before (https://dev.ti.com/tirex/content/simplelink_lowpower_f3_sdk_8_40_00_61/docs/drivers/doxygen/html/_i2_c_8h.html) there two I2C modes that may be used: blocking and callback. For blocking, the I2C_transfer function will not return until it's done. In callback, the transactions are queued. I recommend reading this section for more information.

Additionally, please refer to the I2C source code in the SDK. All of the drivers have their source code availabe in the SDK. You can refer to <sdk>/source/ti/drivers/i2c

sjmizuta said:

I believe the content you are addressing pertains to cases where the CC2340R5 is receiving. When the CC2340R5 is transmitting, can the clock-stretching function be used if the transmission data is not ready or if other high-priority processes are being executed?

Is there anything the user needs to do in such situations?

Are you referring to the Target or Controller? The Controller should handle all of that for you. The Target however, the developer will need to implement. There is a portion of the TRM that implies the target may stretch the clock:

I've contacted a colleague for more information regarding this.

sjmizuta said:

Q3)Please tell me about the operations within the driver.

Since it's confirmed in Q2 that the clock-stretching function can be used, can the driver autonomously use this function to pause I2C communication when a higher priority process conflicts, and then resume I2C communication once the priority process is completed?

Please refer to the driver source code and the driver information.

Best,

Nima Behmanesh

Hi, Nma.

Thanks for the reply.

Q1)

Regarding Q1, I apologize for the confusion.

To put it simply, for the controller, you just need to perform the I2C_transfer() from the API reference.

For the target, I wanted to reconfirm that by merely executing I2CTarget_start() and manipulating data within the callback function: targetCallbackFxn(), as described in the example, I2C communication can be performed without issues.

I wish to confirm that necessary voltage operations on the I2C bus, such as start, stop, and ACK, do not require the user to manipulate registers, etc. Additionally, I would like to know whether these operations are performed by the device via hardware or software.

Q2)

Regarding Q2, it's the same; I want to confirm whether the clock-stretching function can be used during read/write operations regardless of whether it's the controller or target.

Also, I'd like to know if any special operations beyond executing the API, such as setting registers by the user, are necessary.

Q3)

I will close Q3.

I apologize for asking repeatedly, but I appreciate your cooperation.

Best　Regards.

Hello, Nima.

I understand completely, thank you.

Let me confirm just two more points:

Q4) In the case of the controller, there's no clock-stretching function.

In other words, if the counterpart (target) of CC2340R5 tries to use SCL for clock stretching by pulling it low, will CC2340R5 forcibly continue the communication?

Q5) If a higher priority task arises during I2C communication with CC2340R5 as the controller, does it simply pause clock output and restart clock output after resuming the task?

Best Regards.

Hello,

sjmizuta said:

Q4) In the case of the controller, there's no clock-stretching function.

In other words, if the counterpart (target) of CC2340R5 tries to use SCL for clock stretching by pulling it low, will CC2340R5 forcibly continue the communication?

I believe so. I've asked a colleague to get more information regarding this.

sjmizuta said:

Q5) If a higher priority task arises during I2C communication with CC2340R5 as the controller, does it simply pause clock output and restart clock output after resuming the task?

Reading through the driver code, it appears that during the transfer, interrupts are disabled. However, the driver code should be analyzed since the implementation is public.

Best,

Nima Behmanesh