Micro only starts with debugger or nRST manually pulled low

[kylepennington]

Posted on December 12, 2016 at 00:44

I am using the STM32F469 on three devices. One device works fine and starts normally after the power is applied. The other two only start operating after the nRST pin is briefing pulled low. There is 3.3V on nRST after powering it up, indicating the power on reset is ok, but the micro fails to start running.

Attaching the STM debugger and checking the MCU core it says it is halted. Clicking run starts the device working.

What could cause the device to power up correctly but not start the program running?

[kylepennington]

Posted on December 13, 2016 at 23:24

I have tried commenting out the SystemClock_Config so that it only inits HAL then turns on LED. The LED turns on with debugger but not standalone. I want to try running the code with just registers/assembly though.

I've tried all the possible combinations. The options I use (which work on other device) are: 

WDG_SW: checked

nRST_STOP: checked

nRST_STDBY: checked

BOR off

no read protection

I'll try shorting those two components.

Yeah it looks crap. Next version I'll modernise.

[kylepennington]

Posted on December 13, 2016 at 23:27

I tried level 3 but it didn't change anything.

[waclawek.jan]

Posted on December 13, 2016 at 23:57

What does

only inits HAL

mean? Can't be the problem in 'only inits HAL'?

How comes you've shown us a monotone rise in VDD previously, and now there's that dip down to some 2V? What are the differences in the circuit then and now? The dip starts while the mcu is still in reset, so it's hard to accuse it of causing it.

The dip in power supply is what throws off the simplistic resets, but IMO the POR/BOR in STM32 should be OK in that respect. I had expectations towards BOR being set, too. Please take that measurement with BOR enabled - you should see the reset extend beyond the dip.

What do you want to modernize?

JW

[kylepennington]

Posted on December 14, 2016 at 00:08

Yes, quite possibly it could be in initialising HAL. I'll try and get the LED going with just registers.

I'm not actually sure what changed to cause the dip. I changed bench power supply, so possibly that...

Here is the same plot with level 3 brownout.

I will modernise the schematic value notations. 

[waclawek.jan]

Posted on December 14, 2016 at 00:22

That's a hummm then... it looks exactly as it supposed to look.

Please don't change the value notations just because of my dumb comment.

[kylepennington]

Posted on December 14, 2016 at 01:28

OK I added the code below to the start of the main routine. The LED flashes with debugger or hard reset but not on power up.

void delaysw(int dtime){
 volatile int i;
 while(dtime--) for(i=0;i<25000;i++);
}

int main(void)
{
 RCC->AHB1ENR |= RCC_AHB1ENR_GPIOEEN;
 GPIOE->MODER |= GPIO_MODER_MODER11_0;
 GPIOE->OTYPER &= ~GPIO_OTYPER_OT_11;
 GPIOE->OSPEEDR |= GPIO_OSPEEDER_OSPEEDR11;
 GPIOE->PUPDR &= ~GPIO_PUPDR_PUPDR11;
 while (1)
 {
 GPIOE->BSRR = GPIO_BSRR_BS_11;
 delaysw(10);
 GPIOE->BSRR = GPIO_BSRR_BR_11;
 delaysw(10);
 }�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

[kylepennington · Accepted solution]

Posted on December 14, 2016 at 04:58

I measured the resistance between the BOOT0 pin and GND and found it was around 40K. There was dodgey connection between the jumper pin and the pull down resistor. Hardwiring the jumper pin to the pulldown resistor fixed the problem.

Thanks for your suggestions.

[waclawek.jan]

Posted on December 14, 2016 at 10:26

Now here shows the weakness of this new forum - there's wealth of tags and rewards and stuff, so I gave you a Nice Work badge, but it should've really been a Perseverance in Hardware Debugging badge.

Jan