Using a STM32G0F06
I have a bootloader/application that I am debugging. I am facing a strange problem. Often, I command the app to drop to bootloader (via a software reset). When I execute the software reset code, occasionally the core locks up.
Here is a video showing the core registers and the disassembly as I step debug through the reset code:
https://youtu.be/8SxjNWpSIss
A couple of questions:
Is this a MCU core lockup? If not, what is it? Does the PC go to 0x1FFF19A6 during a core lockup, or is that just random?
How come the IWDG I have configured does not reset the MCU after it has locked up?
Does it get locked up to? Is there some way I can programmatically recover from a core lockup: MCU pulls its' own external reset pin low?
If the PC has the value 0x1F... I suspect that it is not locked up but running the internal boot ROM. The boot ROM will either kick the watchdog itself or maybe turn it off, so that is why you can't rely on the watchdog to get out of it. ST probably don't want you to debug the ROM, so maybe that is responsible for your further problems.
See AN2606 for how to make sure you don't go into the boot ROM after you reset.
I have MCU STM32F415xx and was trying to write on internal flash. But for reason I don't know PGPERR and PSGERR flags were turning on in random time (as I found, problem can be found anywhere in HAL libraries) and HAL functions were stopping. I turned out flags checkout in FLASH_WaitForLastOperation. And after that MCU is not responding on any try to connect. Reference manual says, that if this flags are on, flash operations just will not be performed, but my MCU is not working and I cannot connect to it with ST-LINK Utility (and Programmer as well) even with reset pin. So what could happen and is there any way to reanimate my MCU?
As announced in the title of the post, I am working on STM32 which I want to connect thanks to the Ethernet and LWIP config. Right now, I just want to ping my card.
I followed several tutorials on websites and youtube. My setup is good. I can ping my card at the address configured in lwip.c
BUT I can only ping with the debugger and I need to force the run 4 times to be able to ping and to call my main.c
For a simply soft to blink led, your build, your flash and the system run.
In my case, i need to run 4 times and i can do that only with debugger.
That's happened just if MX_Lwip_init() or/and MX_LWIP_process() are called
I think something happened when i build but i don't know what.
Thanks if someone have response
Have a good day !
I have designed and assembled a PCB. All connections are fine and leds are blinking when i open the CUBEMX. But I don't know what to do after this point. Do I need to put some drivers before using DFU?
If so, i don't have an ST-LINK Programmer how can i use the only input for this pcb (which is PB11,PB12 as AN2662 suggests). Its also interesting that device is responding to CubeMX . Does device has any code in it?
MCU :
STM32F405RGT6
Your question is not clear. But i will try to answer to your question with my understanding from the question. First thing that you need to find the datasheet of mcu. Now, you can able to find related pins for programming. Using these pins, you can program your hw.
if you want to put dfu mode to your hw, Please check "Application Note 2606 STM32 microcontroller system memory boot mode".
Also, i wrote post about system memory bootloader, here is the link: https://engineeringvolkan.wordpress.com/2020/05/08/1928/
If I understood well, you want to learn how to upload code into your uC. If you are not familiar with DFU, I suggest that you can use ST LINK V2. However, the important point is whether, or not you put output terminals for SW pins (SWDIO, NRST, SWCLK, SWO).
For the DFU, you should check Bootloader properties and bootloader configurations specifcally related to your uC. After these, you can watch this video EEVBlog STM32 DFU and inspire from it.
My question is, if I manage to develop some kind of bootloader and flash it (is it called that when you put a bootloader on an MCU?), and it works horribly, can it brick the MCU entirely, making it completely unusable, permanently?
The reason I'm asking is that I've been tasked to develop a bootloader for the STM32F407. Problem is, I don't know anything about bootloaders or anything of the sort, which means that I have a lot to learn.
I appreciate any answers, thank you!
In short no you cannot brick a microcontroller with a bootloader.
In the end bootloader is just a firmware and can be erased away using the programmer via SWD
Erase the flash and your controller is as good as new
In general, absolutely, I have a collection of bricked microcontrollers, every so often I get lazy and there goes another.
It is very specific to your microcontroller and family. For example, pin count is very important, as much bang for your buck as you can get, if your microcontroller relies on certain pins for in circuit (or even in a programming fixture) and those pins can be repurposed by software. For example jtag pins that can also be gpio pins. And your code for some reason uses them as gpio pins, AND the design of the chip is such that they cannot use the jtag interface when the chip is in reset, then you can get bricked.
Another very easy one is the pll or clocks in general. If/as you develop code to initialize the clock system (assuming you choose to do that, even if you use chip vendor supplied code) and you have a bug that switches the chip over to a clock that you have not properly initialized or isnt there, it might brick.
Now some chip designs, many, help you out in various ways. The AVR family in general there is a programming mode that happens while the chip is in reset or is related to reset such that whatever code is in flash cannot affect its functionality, you can have a bad board design, sure, but your code cannot prevent it from working. Another method is a "strap" a pin (or pins) that is dedicated to a boot function, set one way normal boot, tie it the other and it goes into an alternate bootloader. This is what you have on the stm32 boot0 and sometimes boot1 depending. that is your get out of jail free card for that chip family, if you brick your chip (pll/clock or mess up the SWD pins by using them as gpio), you "simply" change boot0 and it boots into an internal bootloader (which AFAIK you cant mess up) which is known to work. From that bootloader you can use SWD (chips not bricked now) or the bootloader itself (always serial, sometimes usb or other is supported). NXP similar deal. Atmel ARMs used to have (do have) SAM-BA now they really only support SWD, you can get some samba code and try to lock it into the flash, but way too easy to unlock and or trash that flash, so that is a fail on their part.
As part of your system design if you dont have one of these built into save you from bricking features (like boot0 on an STM32), then I recommend you add one. Very early code initializes a dedicated gpio pin as a strap into your software, if that gpio pin is pulled one way do a normal boot, if pulled the other then spin in an infinite loop or jump to some other guaranteed to not be buggy code. Not a complete guarantee that you wont build the project wrong and trash this code, but it at least allows you to develop your bootloader/project and not brick a tray full of parts/boards as you work through the peripherals that can brick it.
Note letting smoke out of the part is another way to brick it as well, and that can/does happen from time to time as well.
Lots of examples on how to boot an STM32, plus various code from ST that you can use as a starting point as well. (all of which is of various quality, you get what you pay for). Their docs are good, better than some of the competition, not difficult at all to boot and configure their peripherals, sometimes easier than trying to use a canned library. YMMV, you should try various solutions. But if you are new to this, bricking is highly likely, fortunately you have a chip that you cant brick so long as your board design breaks out the boot0 pin. For a prototype board for an STM32 I prefer to have a boot0 button and a reset button, just reset resets the chip and runs, hold boot0 and press reset and it goes into the bootloader. both have to be wired in properly with the right pull up or down as needed for this task. or a jumper works tie boot0 directly high or low then pop reset, costs you more time, but works.
Yes You can brick the Micro controller to never recovered state. I did this and i did it in STM32F427.
Bootloader is all about carefully selecting Clocks, Peripharals and Interrupts priority. if you do this, there are less chances to brick the controller. Also test everything before release your code as some companies wants to save proprietary information to be saved so they blow up the JTAG lines, the only way to program is via Bootloader and if it is not perfect, voila, you just bricked the controller.