STM32 system low temperature problem

[John F.]

Posted on October 04, 2010 at 11:44

STM32 system low temperature problem

[dthedens2]

Posted on May 17, 2011 at 14:10

All you need is a home refrigerator/freezer to get to 2 C.

I would check the oscillator. just one unit or all of them (cold solder joint, bad part) is the crystal spec'ed to that temperature range?  is it a quality part?  I assume you wait for the clock to be stable, the PLL stable. do you handle other fault interrupts? If the oscillator is not really stable, then other fault interrupts may occur. just suggestions, good hunting.

[Andrew Neil]

Posted on May 17, 2011 at 14:10

''All (sic) you need is a home refrigerator/freezer to get to 2 C.''

But you also need to have the unit in question to hand to put into that fridge - which, he says, he doesn't... ;)

[cschumann]

Posted on May 17, 2011 at 14:10

Hi John,

We are using the STM32F103RET7 in one of our designs. For the product tests we cooled some of the devices down to -40°C (with low humidity). While cooling down, remaining at -40 and heating up, the devices worked all the time. Used peripheral was: ADC, SPI, TIM, USART, CAN. Carsten

[John F.]

Posted on May 17, 2011 at 14:10

Thanks to everyone who replied. I hope to get the system back for testing and I expect the fault will eventually be found. I just wanted to ''shoot a line'' in case any one knew of any particular problems with the STM32.

Carsten, it's reassuring that your tests were successful - thanks for sharing your results - so I expect my core STM32 system should be capable of running too. I'll post again if I find an STM32 specific problem but otherwise assume the problem is somewhere else in my system (or in my software!). Thanks again to everyone who offered help.

[cschumann]

Posted on May 17, 2011 at 14:10

John,

Some more things you could check:   - have you checked your board for condensation between the pads?   - is your power support stable?   - is your board hand-soldered? If yes, there could be contact problems. If you have an oscilloscope, you could try to check the supply voltage and the oscillator pins. Maybe you get a hint to the problem. Best regards, Carsten Schumann  

[John F.]

Posted on May 17, 2011 at 14:10

For anyone interested, this seems to be a race between the STM32 following reset and external hardware ... maybe the I2C bus. I'm relying on the STM32 internal reset. (clive1, Hi! I know you would have recommended an external reset chip.)

I suspected the HSE wasn't starting so I added code to check the HSE and signal if it had failed but it always seemed to start OK. Attaching the debugger to a stalled system seemed to show it was stuck in an I2C check flags function. Adding code to enable the IWDG seemed to reliably start the system after initial failure as the IWDG fired some 10s later. As another check, I inserted a 1s delay between switching to the HSE and all the other configuration, int main(void) {   //enable the Independent Watchdog   IWDG_WriteAccessCmd(IWDG_WriteAccess_Enable); //access IWDG_PR and IWDG_RLR   IWDG_SetPrescaler(IWDG_Prescaler_256);        //256= ~156Hz (75% or 150% possible)   IWDG_SetReload(1560);                         //12 bit down counter (0..n-1), ~10s (6.6s..13.3s)   IWDG_ReloadCounter();   IWDG_Enable();   DBGMCU_Config(DBGMCU_IWDG_STOP, ENABLE);      //Debug IWDG stopped when Core is halted  //note SystemInit() was called in RCC_Configuration but is now called separately so that the   //High Speed External Oscillator can be checked and action taken if it has not started   SystemInit();   //wait for ~1s (at 72MHz) with no compiler optimisation   for(Time = 0; Time < 2666666L; Time++);   //bit RCC_CR_HSERDY will be set in RCC->CR if HSE has started, test and handle failure here   if((RCC->CR & RCC_CR_HSERDY) == 0) HandleHSEFailure();   //else proceed as normal ...   RCC_Configuration();   I2C_Configuration();    //configure I2C before enabling port pins   GPIO_Configuration();   ADC_Configuration();   USART_Configuration();   DMA_Configuration();   NVIC_Configuration();   Timer1_Configuration();   Timer2_Configuration(); Now, after including the 1s delay, the system seemed to start reliably every time - even at low temperatures. I noticed my 3.3V supply took about 1ms to rise monotonically to stable 3.3V but the STM32 data sheet says the microcontroller part has reset temporisation TRSTTEMPO of 1 / 2.5 (typ) / 4.5 ms so you might think that was long enough to allow external hardware to complete reset (although the STM32 reset threshold is about 1.92V so it may have a ''head start''). If anyone has comments on the problem on the fix(es) or my code I'd like to hear them. thanks.

[John F.]

Posted on May 17, 2011 at 14:10

Hi, thanks for taking an interest. I think the HSE is operating correctly. I modifed the HSE startup so that SystemInit() always returns even if the HSE has not started. I then added the

    if((RCC->CR & RCC_CR_HSERDY) == 0) HandleHSEFailure(); which flashes an on-board LED if the HSE is not ready. The program doesn't fail there (though I've confused you by putting the HSE check after the 1s delay). I think the program fails in the I2C hardware. There are two devices. An LTC4151 which is powered by and monitors a 28V supply and an M24C64WMN6P EEPROM which is powered by a 3.3V supply. They are both on the I2C bus. When the 28V supply powers up the LTC4151 is powered on. The 28V then also powers a 6V supply which powers the 3.3V supply. I wondered if there is some kind of race where the LTC4151 has taken control of the I2C bus (it has a stuck bus reset circuit) before the +3.3V supply has powered up ... so there's a clash between the LTC4151 and the STM32 internal I2C engine which gets to see the bus some time after the LTC4151. Annoyingly, the problem only seems to occur at startup at lower temperatures but even then, once started it works reliably. There's some kind of problem with initialisation and it's not that the HSE doesn't start. It looks like either the IWDG can recover the system when it fires or the system starts up properly if I allow 1s between STM32 reset startup and attempting to initialise the rest of the STM32 (including the I2C). ST's I2C code does include some while loops which can hang forever and a more robust I2C driver might also fix things ... however, I can't make this my life's work. I rejuvenated this post because I was interested to hear if anyone else had suffered similar problems or had any better ideas than mine. All views welcomed. Thanks again for your thoughts.

[Tesla DeLorean]

Posted on May 17, 2011 at 14:10

<G>

A second seems like quite a while. Have you thought about using the instruction cycle counter in the core to a) limit the loop iterations to 1 second or HSE ready, and b) measure the time for the HSE to come up in the cold. Or do you think it requires additional time after HSE is ready, and the second gets you into the post HSE ready region? If that is the case maybe the delay could be shorter, and you could add a smaller stabilization delay after HSE goes ready.

[Popcorn]

Posted on May 17, 2011 at 14:10

Hi John,

Have you had any progress with this issue?

I'm using an STM32F103VET6 using ADC, SPI, USB, USART and TIM

Everything works great down to about 0C, then the SPI will not work until the SPI hardware is sufficiently warm. Depending on how far below freezing the ambient temperature is that could take minutes to occur.

If I disable SPI on my device, all other peripherals work down to -30 Celius. I haven't tested any lower than that. I'm assuming this could be somewhat related to your issue as SPI and I2C go hand in hand on the STM32.

BTW, SPI can be initialized at any temperature and it will not hold up the system, but as soon as I do a BufferRead the system seems to infinitely loop.

I was going to make a post about it tonight, but I'm searching around to see if anyone has had the same problem and resolutions and stumbled across yours.

Thanks,

Patrick