CC3235SF:I cannot follow the status of SCL and SDA on the I2C line via software.

Hi,

Can you describe better your I2C recovery procedure? Why you are using such approach with CC32xx devices reset? This approach cannot work properly when state machine inside I2C chip stuck at wrong state. Usual way regardless of type MCU is switch SCL line to GPIO out and generate few clock (SCL) pulses.

Jan

I am using TI_RTOS. I enter sleep mode with LPDS mode and the system wakes up with http requests. I am using I2C in blocking mode. The system locks the processor due to the I2C line. Even the Whatcdog timer locks. I am investigating the reason for this. Therefore, how can I control the I2C line without locking the system or where am I making a mistake? There is a timeout mechanism in I2C but the system locks despite it. Especially when there is an error in the slave device communicating with I2C, when the integrated slave device fails, the system wants to communicate with I2C but when the slave device does not respond, the whole system locks. Despite the Whatcdog time, it does not work and the system locks. There is no such problem when there is no I2C.

Hi,

Hard to say, but there need to be something significantly wrong inside your code. There is no reason for MCU crash or "freezing" due to issue at I2C bus. I never seen even such issues with watchdog. According my experience is Watchdog at CC32xx devices very reliable. Only issues which I remember are Watchdog lock-up when wrong signal is feed to hardware reset PIN.

I use CC3220 which have exact same peripherals like CC3235. I use TI-RTOS but with driverlib library. I do not use ti-drivers with Sysconfig. This is because my project started before Sysconfig was available. Other reason is that ti-drivers drastically decrease features available by hardware itself. Last reason that ti-drivers are buggy even at latest SDK versions.

Are you sure that you have issue with Watchdog reset? What about issue with device startup after reset due to hardware issue (e.g. freeze in bootloader due to parasitic powering via internal protection diodes, wrong SOP mode and floating UART RX pin, etc.)?

Jan

I have no such problem without LPDS mode. In LPDS mode the system draws 1ma current. When there is an error in the i2c line while drawing 1ma current, for example, I turn off the power of the slave device, in this case it locks up when trying to communicate. If I do the same operation without LPDS, the system draws 30mA and when I turn off the slave device's energy and try to communicate while drawing 30mA, there is no deadlock. I also used callback mode, I used blocking mode, I don't know which one to use. I couldn't solve my problem.

Hi,

For me it looks like a problem with hardware design. If your hardware have multiple power bus which can can be switched off, you need to properly handle especially when you are using low-power modes. Maybe you should check how do you park pins before entering LPDS mode.

Jan

/*  I2C Callback Fonksiyonu */
static void I2C_Callback(I2C_Handle handle, I2C_Transaction *transaction, bool transferStatus) {
transferComplete = true;
 SemaphoreP_post(i2cSemaphore); //  İşlem tamamlandığında semaphore'u serbest bırak

if (!transferStatus) {
 I2C_cancel(i2cHandle); //  Hata durumunda I2C işlemini iptal et
}
}

void initI2C(void) {
I2C_Params i2cParams;
I2C_Params_init(&i2cParams);
i2cParams.transferMode = I2C_MODE_CALLBACK; // Non-blocking mode
i2cParams.transferCallbackFxn = I2C_Callback;
i2cParams.bitRate = I2C_400kHz; // 400kHz hızlı mod

i2cHandle = I2C_open(0, &i2cParams);
if (i2cHandle == NULL) {
// I2C başlatma başarısız oldu, hata yönetimi yapılabilir.
}

// İşlem tamamlanmasını beklemek için bir semaphore oluştur
SemaphoreP_Params semParams;
SemaphoreP_Params_init(&semParams);
semParams.mode = SemaphoreP_Mode_BINARY;
i2cSemaphore = SemaphoreP_create(0, &semParams);
}   In this way, I use it with the callback structure. In this structure, the i2c line should not block other parts of the code, correct? 

Hi,

I don't see anything significantly wrong with that code.

Jan