2010-10-02 12:54 AM
STM32F108C8T6 - I2C lock-up
2011-05-17 05:09 AM
STM32F108C8T6 - I2C lock-up
(test of forum search)2011-05-17 05:09 AM
I made that post because putting ''STM32F108C8T6 - I2C lock-up'' into the search box gave no hits!
I thought that might just be because the search doesn't include the thread title - but the search still fails with that text in the body of a post! The search even fails if I just search on ''STM32F108C8T6'' !!2011-05-17 05:09 AM
Hi ,
I don't have deep knowledge about your application but just a question why you don't make your software more robust: repeat { read button_1 GPIO if button_1 is pressed { turn led_1 on; turn led_2 off; } else { read button_2 GPIO if button_2 is pressed { turn led_1 off; turn led_2 on; } } } forever Perhaps that avoid you debugging your application. A+,2011-05-17 05:09 AM
Because this is just a test case that illustrates the problem!
2011-05-17 05:09 AM
Is the STM32F108 a new part?
did you mean ''103'' or ''101''2011-05-17 05:09 AM
''Is the STM32F108 a new part?''
Ahem - no, it's a typo!''did you mean '103' or '101''' Yes - I meant '101' >blush< Well spotted!STM32F101C8T62011-05-17 05:09 AM
The AN2824 ''Optimised'' I2C example includes a wait for the STOP bit to be cleared at the end of a transmission:
/* Program the STOP */
I2Cx->CR1 |= CR1_STOP_Set;/* Make sure that the STOP bit is cleared by Hardware */
while ((I2Cx->CR1&0x200) == 0x200); There is no Event defined for this, and it is not mentioned in the Reference Manual - is it important?2011-05-17 05:09 AM
Rev 11 of RM0008 states,
Bit 9 STOP: Stop generation The bit is set and cleared by software, cleared by hardware when a Stop condition is detected, set by hardware when a timeout error is detected. In Master Mode: 0: No Stop generation. 1: Stop generation after the current byte transfer or after the current Start condition is sent. In Slave mode: 0: No Stop generation. 1: Release the SCL and SDA lines after the current byte transfer.Note: When the STOP, START or PEC bit is set, the software must not perform any writeaccess to I2C_CR1 before this bit is cleared by hardware. Otherwise there is a risk of
setting a second STOP, START or PEC request.
2011-05-17 05:09 AM
Yes - I've just spotted that!
So why is there no event defined for checking that with I2C_CheckEvent() ? And why is the CR1_STOP_Set definition local to the stm32f10x_i2c.c library file and, thus, not available to the application for use? And why is it not shown in any of the ''Transfer sequence'' diagrams? And why is it not done in any of the other I2C examples? etc, etc. Just off to try it now...