STM32F103CBT6 CPAL I2C freezing main loop

[neil239955_st]

Posted on May 15, 2013 at 17:36

Hi all,

I have been using the CPAL I2C library on a STM32F103RBT6 to communicate with an external device which works fine.

I have run the same code on a target board containing a STM32F103CBT6, I2C1 is used so I have not changed any configuration between the uC's.

The following code works on the STM32F103CBT6

uint8_t dataA[] = { 55u, 55u };

uint8_t dataB[] = { 1u, 2u };

 

/*  CPAL_I2C_Write */

I2C_writeRead(&I2C_DevStructure, 0xA0, dataA, dataB, 2U, 1U);

I2C_writeRead(&I2C_DevStructure, 0xA0, dataA, dataB, 2U, 1U);

However the code below appears to hang in the CPAL functions

uint8_t dataA[] = { 1u, 1u };

uint8_t dataB[] = { 1u, 2u };

 

/*  CPAL_I2C_Write */

I2C_writeRead(&I2C_DevStructure, 0xA0, dataA, dataB, 2U, 1U);

I2C_writeRead(&I2C_DevStructure, 0xA0, dataA, dataB, 2U, 1U);

The processor continues to run any code using interrupts as its not in the main loop with the call to I2C_writeRead.

Looking at a scope/debugger what appears to happen is on the second call to I2C_writeRead() no data is transmitted on the I2C pins and the code gets stuck looping around the I2C interrupt handler - CPAL_I2C_EV_IRQHandler()

Could there be some difference I havent seen between the STM32F103RBT6 and STM32F103CBT6 that would cause such a problem?

Any help would be much appreciated.

[onderdelen]

Posted on May 31, 2013 at 14:32

I ran into a similar problem on a custom board using the STM32F372RC with CPALv2.

After going through the code, I found a bug in the CPALv2 library.

An #endif was place wrongly in stm32f37x_i2c_cpal.c on line 888 in

uint32_t CPAL_I2C_Read(CPAL_InitTypeDef* pDevInitStruct)

(around line 888)

/* Wait until TC flag is set */

__CPAL_I2C_TIMEOUT(__CPAL_I2C_HAL_GET_TC(pDevInitStruct->CPAL_Dev), CPAL_I2C_TIMEOUT_TC);

/* Set Nbytes to zero */

CR2_tmp &= ~I2C_CR2_NBYTES;

#endif /* CPAL_16BIT_REG_OPTION */

}

This means that the variable CR2_tmp will not have the NBYTES field reset when CPAL_16BIT_REG_OPTION has not been defined. As a consequence, when receiving an even amount of data, bit 16 of CR2 is still set and the total becomes an odd number, thus causing a mismatch between DMA (even number of data) and STOP handling (even +1 = odd) number of data.

Also, the routine doesn't wait anymore for the setting of the TC flag after sending the register address to the I2C device.

The solution is simple : move the #endif toe the line before /* Wait until TC flag is set */

#endif /* CPAL_16BIT_REG_OPTION */

/* Wait until TC flag is set */

__CPAL_I2C_TIMEOUT(__CPAL_I2C_HAL_GET_TC(pDevInitStruct->CPAL_Dev), CPAL_I2C_TIMEOUT_TC);

/* Set Nbytes to zero */

CR2_tmp &= ~I2C_CR2_NBYTES;

I didn't check this yet in the CPALv1 library, but it could well be the cause of your problem.

Does anyone at ST read this, in order to fix the bug in the library?

Best regards,

Ewout Boks

________________

Attachments :

Schermafbeelding_2013-05-31_om_14.21.46.png : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0sP&d=%2Fa%2F0X0000000bev%2FtiJwaSnbnxI4S9P1f2xDNNv73iallJuOeez3.LmeZVU&asPdf=false

[onderdelen]

Posted on May 31, 2013 at 14:40

I just checked CPALv1. The CPALv2 bug isn't there. Also, the I2C registers in the STM32F1 are totally different from those in the F3. It appears the I2C in the  F0 is similar to the F3, and the F1,F2 and F4 share a different I2C peripheral.

Ewout

[emalund]

Posted on May 31, 2013 at 20:16

I have been using the CPAL I2C library on a STM32F103RBT6 to communicate with an external device which works fine.

 

 

I have run the same code on a target board containing a STM32F103CBT6, I2C1 is used so I have not changed any configuration between the uC's.

 

same size pull-up resistors?

same load capacitance (stray)?

[neil239955_st]

Posted on June 13, 2013 at 14:39

Thanks for the replies,

It would be quite awkard to put the boards on an LCR meter at the moment but I would say the capacitance of own board is quite a bit higher with the I2C device being attached to an FFC ribbon.

Originally the pullups were the same but after using an oscilloscope I reduced the pullups from 10K to 2K7 on my own board to correct the rise times due to the higher capacitance.

I now have around 1uS rise time which I had previously been informed was correct for around 100kHz I2C?

Since originally posting I have implemented software I2C using bitbanging which works correctly even at 300kHz while the CPAL library was crashing at 100kHz so I believe the hardware should not be causing a problem.

I will have a quick look through the library to find any rogue #endifs