STM32F103 Does not RESET on Power Reset

[pkumar1883]

Posted on March 26, 2016 at 09:46

Dear All,

I am facing a very strange problem in STM32F103RET6. It is showing completely random behavior on Power Reset. On some PCBs it RESET on every power Reset, while both PCBs have same hardware(means identical hardware , components etc). In my design I am using two STM32s(on each side of PCB). One is working perfectly in all boards. The boards which are showing problem require to put on zero power for few minutes.   

[Tesla DeLorean]

Posted on March 26, 2016 at 11:07

How are you treating NRST and BOOTx in your design?

[pkumar1883]

Posted on March 26, 2016 at 13:02

Dear Clive1,

Thnak you for your reply. My NRST and BOOTx pins configuraion are as follow-- NRST   ---- Open circuit BOOT1 ---- Open Circuit BOOT0 ---- Pull Down with 1K

[Tesla DeLorean]

Posted on March 26, 2016 at 18:59

So the two STM32 don't share a common reset, and you don't have a power-on-reset circuit.

Can you add any diagnostic output code to the boards where the system is dysfunctional and confirm which part is not starting, and what inactions are/are not occurring? If you add a power-on-reset and connect the two resets, for the processors and any other synchronous parts, does the behaviour become any more predictable?

[TDK]

Posted on March 27, 2016 at 18:48

NRST should have a pullup.

[pkumar1883]

Posted on March 28, 2016 at 10:32

Dear kostka.tim,

Thank you for reply. I think a permanent pull up will stop watchdog reset execution.

[pkumar1883]

Posted on March 28, 2016 at 10:45

So the two STM32 don't share a common reset, and you don't have a power-on-reset circuit.

Yes they don't share a common reset , I have no power-on-reset circuit.

Can you add any diagnostic output code to the boards where the system is dysfunctional and confirm which part is not starting, and what inactions are/are not occurring?

Yes I tried to debug by doing the following step-- 1. Configure Clock to HSE(16 MHZ). 2. Call Rcc_Init() to enable GPIOx clock. 3. Switch On LED and give a beep on Buzzer. As I told that this reset problem is totally random. Sometime LED and Buzzer do their job but some other time they don't.My test code is as below-

int main(void)

{

RCC_Configuration();

RCC_Init();

SysTick_Config(72000000 / 1000);

setup_IWDG();


BuzzerInit();

initLEDs();

BuzzerBeep(1, 1000);//run buzzer for 1000mS

LEDTest();

 //go to main task
 while(1){}


}

void RCC_Configuration(void)

{

ErrorStatus HSEStartUpStatus=!SUCCESS;

Flag_HSE_Active=RESET;Flag_HSI_Active=RESET;

RCC_DeInit();

RCC_HSEConfig(RCC_HSE_ON);

HSEStartUpStatus = RCC_WaitForHSEStartUp();


if(HSEStartUpStatus == SUCCESS)

{

RCC_HCLKConfig(RCC_SYSCLK_Div1);

RCC_PCLK2Config(RCC_HCLK_Div1);

RCC_PCLK1Config(RCC_HCLK_Div2);

FLASH_SetLatency(FLASH_Latency_2);

FLASH_PrefetchBufferCmd(FLASH_PrefetchBuffer_Enable);

RCC_PLLConfig(RCC_PLLSource_HSE_Div2,RCC_PLLMul_9);


RCC_PLLCmd(ENABLE);

while(RCC_GetFlagStatus(RCC_FLAG_PLLRDY) == RESET){}

RCC_SYSCLKConfig(RCC_SYSCLKSource_PLLCLK);

while(RCC_GetSYSCLKSource() != 0x08){}

Flag_HSE_Active=SET;

}

else {

RCC_HSIConfiguration();

Flag_HSI_Active=SET;

}


}

void RCC_HSIConfiguration(void)

{

RCC_DeInit();

RCC_HSEConfig(RCC_HSE_OFF);

RCC_HSICmd(ENABLE);

while(RCC_GetFlagStatus(RCC_FLAG_HSIRDY) == RESET);

FLASH_PrefetchBufferCmd(FLASH_PrefetchBuffer_Enable);

FLASH_SetLatency(FLASH_Latency_2);

RCC_HCLKConfig(RCC_SYSCLK_Div1);

RCC_PCLK1Config(RCC_HCLK_Div1); // div 2 ? apb1 max 36mhz

RCC_PCLK2Config(RCC_HCLK_Div1);

RCC_PLLConfig(RCC_CFGR_PLLSRC_HSI_Div2,RCC_CFGR_PLLMULL16);

RCC_PLLCmd(ENABLE);

while (RCC_GetFlagStatus(RCC_FLAG_PLLRDY) == RESET);

RCC_SYSCLKConfig(RCC_SYSCLKSource_PLLCLK);

while (RCC_GetSYSCLKSource() != 0x08);

RCC_SYSCLKConfig(RCC_SYSCLKSource_HSI);

while (RCC_GetSYSCLKSource() != 0x00);


}

void RCC_Init(void){

RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA |\ 
 RCC_APB2Periph_GPIOB | RCC_APB2Periph_GPIOC | \ 
 RCC_APB2Periph_GPIOD | RCC_APB2Periph_AFIO | \ 
 RCC_APB2Periph_USART1 |RCC_APB2Periph_ADC1 |\ 
 RCC_APB2Periph_ADC2 , ENABLE);//

RCC_APB1PeriphClockCmd(RCC_APB1Periph_CAN1| \
 RCC_APB1Periph_USART2 | RCC_APB1Periph_USART3 | \
 RCC_APB1Periph_UART4 | RCC_APB1Periph_TIM2 | \
 RCC_APB1Periph_TIM3 | RCC_APB1Periph_UART5 , ENABLE);

}

[Tesla DeLorean]

Posted on March 28, 2016 at 23:25

I think a permanent pull up will stop watchdog reset execution.

Why would it do that? Actually driving it high, with a push-pull driver can be a problem because you might not be able to supply enough current to get it close enough to ground to be recognized as zero. A 10K pull-up to the supply is not going to break the watch-dog reset. I understand your problem is random, but you are also indicating it is predictable and reproducible on specific boards. Your task will be to instrument the situation sufficiently so you can understand what is actually happening, and to change the situations in ways that might be illustrative of where the problem is. Sharing a common reset allows you to significantly constrain the interaction between the two parts, if that plays a role in the instability. The parts start running from HSI, and even separated, if you plot the NRST signals on a logic analyzer, it might be apparent if the problem relates to one part not resetting properly, or the order in which they reset.

[pkumar1883]

Posted on March 29, 2016 at 08:27

Dear Clive,

Let me check the NRST waveform of both microcontrollers. Then I will write. What are the chances of ESD distortion.

[pkumar1883]

Posted on March 29, 2016 at 09:28 In above Image I have captured the NRST pin of my both controller. In above image NRST waveform are identical and both controller RESET properly. While in image below both waveform are again same and identical but the controller associated with Green waveform does not RESET(no LED glow no buzzer beep).