Hardware reset problem

[alanrouse9]

Posted on February 28, 2011 at 21:57

Hardware reset problem

[Tesla DeLorean]

Posted on May 17, 2011 at 14:26

If you suspect a reset problem, you should really look into a real POR circuit that can clamp the reset for a defined period after the supply(s) threshold, rather than some RC circuit, on a slow ramping supply, transitioning VIL/VIH. Consider the MCP-120 with a >100 ms hold time, at a threshold that actually meets the minimum operating voltage of the part.

Consider also that the LCD might have different power on and sequencing than the STM32. Also that resetting the STM32 does not reset slave I2C devices. Check also the crystal/oscillator startup in your failure condition. Add some serial port diagnosis to your main/lcd systems, so you can see what the live system is doing, absent a JTAG pod. Check the main system can talk to the lcd, check that the lcd is hearing the main system.

[hanser]

Posted on May 17, 2011 at 14:26

Hi Alan,

If it's a smart display, there is probably a chip in it. If so, just try to delay the initialisation routine. If the power isn't stabilized at power up, perhaps the display need it stable. Then delay its power up if possible. I hope you'll get it working fine

[John F.]

Posted on May 17, 2011 at 14:26

I also had start up problems which seemed to be I2C related. The advice already given is sound. I found that just adding messages sent by UART at start up ''configured RCC'', ''configured GPIO'' etc. fixed the problem (as it added delays).

As previously mentioned, consider the start up time of your display - maybe add a few hundred ms delay before trying to write to it. Check that the I2C bus is not fouled up - be prepared to ''clock out'' the I2C bus if it has errors.

[alanrouse9]

Posted on May 17, 2011 at 14:26

Hi Guys

Thanks for your suggestions.  However, most of them suggested the problem was with the peripherals, I2C or the crystal oscillator.  I use the HSI through the PLL to give a clock of 36MHz.  I have inserted test code as follows: void InitialiseSTM32(void){     InitRCC();     prvInitialiseGPIO();     SetGPIO(TP1);     InitTickTimer(2, 1000);     prvInitialiseInterrupts(); } This should be self-explanatory:  After intilising the clock it configures all GPIO ports as required.  The configuration set a spare GPIO, designated TP1, as an output.  This pin is connected to a test point that I can monitor on a scope.  SetGPIO() forces the designated pin to a '1'.  Thus before any ptimers, interrupts or other peripherals are set up, TP1 should be forced to '1'. If I leave the system powered down for 30 seconds, on power-up there is no change on TP1.  If I briefly interrupt power it does change as expected. The suggestions about timing led me in desperation to modify the code as follows: void InitialiseSTM32(void){     u32 x32;     InitRCC();     x32 = TARGET_SYSCLK / 600;    //    ~100ms     while (--x32);     prvInitialiseGPIO();     SetGPIO(TP1);     InitTickTimer(2, 1000);     prvInitialiseInterrupts(); } This almost completely fixes the problem (although on one ocassion it still failed).  However, I cannot understand why there is a need for an additional delay after initialising the clock, before any other code will run, or why the delay is only needed after the system has been powered down for an extended period.

[John F.]

Posted on May 17, 2011 at 14:26

Do you wait for flags in your RCC init?

RCC_FLAG_HSIRDY: HSI oscillator clock ready RCC_FLAG_PLLRDY: PLL clock ready