How to fix CPAL timeout problem

[jhnlmn]

Posted on January 16, 2014 at 05:33

Hi,

My problem is similar to the following: https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/CPAL%20Spin%20Waits%20in%20Interupt My device used to freeze and have watchdog triggered. I found that it is freezing in one of numerous __CPAL_I2C_TIMEOUT in cpal_i2c.c V1.2.0 21-December-2012, like this one: uint32_t CPAL_I2C_ER_IRQHandler(CPAL_InitTypeDef* pDevInitStruct) ...       /* Wait until Busy flag is reset */       __CPAL_I2C_TIMEOUT(!(__CPAL_I2C_HAL_GET_BUSY(pDevInitStruct->CPAL_Dev)), CPAL_I2C_TIMEOUT_BUSY); I see that there are several other places, where __CPAL_I2C_TIMEOUT can be invoked from ISR. I found that the original authors of my application missed the following comment in cpal_i2c_hal_stm32f10x.h: ''The timeout mechanism interrupt priority should be the highest one and it should be able to interrupt any other ISR.'' Also there is a recommendation to use 1ms tick. But our application was designed with low priority 10 ms systick. This explains the freeze. Now I wonder whether I should change systick interrupt priority and interval to be 1 ms and priority above I2C. But it does not sound right to me. I2C errors (like this busy flag) are really rare. Why should I interrupt important processes every 1 ms just to handle this rare event? And even if I will do it, still my board will freeze for 1 ms. I kind of always believed that interrupt routines should be short and have some reasonable maximum execution time, but it appears that CPAL library has numerous places that may have unpredictably long busy loops or even infinite if one does not have high priority systick. What is the proper way to fix it? Thank you #freeze #cpal #__cpal_i2c_timeout

[chen]

Posted on January 16, 2014 at 13:00

Hi

'' it appears that CPAL library '' I believe that demo/library code supplied by ST is provided as is and without warranty. ie it is normally good for demonstration purposes. Most demo code is rarely thread safe! Use it in a real project at your own peril. (It is however a good starting point - often only needs small tweats to make it good) ''I kind of always believed that interrupt routines should be short and have some reasonable maximum execution time,'' Half true. ISR should be kept as short as possible. There is no golden rule about max execution time - this should be decided on a system and case by case basis. ''our application was designed with low priority 10 ms systick.'' Ask yourself - What is the 10ms systick used for? Is it more or less important that the I2C? ''Why should I interrupt important processes every 1 ms just to handle this rare event?'' Just how heavily loaded is the processor? Is it so busy that it cannot spare the ISR time every 1ms? If the processor has the processing capacity (ie it not busy doing other stuff) then it should make very little difference. ''Now I wonder whether I should change systick interrupt priority and interval to be 1 ms and priority above I2C.'' I think if you answer the 2 points above - you can answer this.

[jhnlmn]

Posted on January 16, 2014 at 20:44

> I believe that demo/library code supplied by ST

> is provided as is and without warranty. > ie it is normally good for demonstration purposes. STM32 MCU itself is also provided without warranty. Does this mean it can only be used for demonstration purposes? > Most demo code is rarely thread safe! > Use it in a real project at your own peril. CPAL is not a demo code. Demo code is in STM32_CPAL_Examples directory. But I am talking about Libraries in Libraries\STM32_CPAL_Driver\src and Libraries\STM32F10x_StdPeriph_Driver\src Those drivers are not demos. They are an official way (and usually most proper way) to program MCU. that most projects that I have seen used as-is. It is really wrong to say about drivers provided by MCU manufacturer. ''Use it in a real project at your own peril.'' > Ask yourself - What is the 10ms systick used for? > Is it more or less important that the I2C? Sure. It is the least important and has the lowest priority. I2C has the highest priority and I want to keep it this way. > Just how heavily loaded is the processor? > Is it so busy that it cannot spare the ISR time every 1ms? processor may not be very busy overall, but it must provide very fast I2C replies. Intermittent delays in I2C handling will be most unfortunate. > I think if you answer the 2 points above - you can answer this. No, my question was not how to redesign my own application - I can figure it out myself, but how to modify CPAL to either get rid of busy loops completely (it will be ideal) or at least get rid of busy loops in ISR. I am sure that CPAL is used in numerous projects and people also faced this bug (like the link I posted above). If they did not yet faced this freeze in ''Wait until Busy flag is reset'' line yet, then they will sooner or later.