cancel
Showing results for 
Search instead for 
Did you mean: 

Could ADC+DMA brick my mcu?

Javier1
Principal

I was happily developing some ADC+DMA routines for my stm32f205 and suddenly my MCU started to freeze.

I am able to connect, erase, and flash binaries with stm32CubeProgrammer trough an ST-link.

After erasing multiple times my STM32F205 with stlink and STM32cubeprogrammer, i am using as debugging code a simple blink programm autogenerated with cubeMX with:

internal clock

SW debugging

and my led pin.

This program is also failing to execute.(it does execute no problem in my nucleo-f207 board)

0693W000008wIOnQAM.pngWhen launching the debugging session i realised the HAL_Delay() function is leading the code to a weird flash non mapped in .elf memory location.

0693W000008wIZHQA2.png 0693W000008wIlcQAE.png 

__________________________________________________________________________________

systick before hal_delay():

0693W000008wIWXQA2.pngsystick after werid jump to memory and debugger looses track of where the code is running

0693W000008wIWwQAM.png nvic_iser4 shows that value when everything goes south..0693W000008wIh1QAE.png 

if i comment out the hal_delay function the blink works....

we dont need to firmware by ourselves, lets talk
1 ACCEPTED SOLUTION

Accepted Solutions
Javier1
Principal

So the problem ended up being damaged MCUs due to too high temperature reflow soldering.

Nothing to do with firmware or software

we dont need to firmware by ourselves, lets talk

View solution in original post

1 REPLY 1
Javier1
Principal

So the problem ended up being damaged MCUs due to too high temperature reflow soldering.

Nothing to do with firmware or software

we dont need to firmware by ourselves, lets talk