#6 ARM Microcontroller Tutorial - 😬 I ** BRICKED ** My ARM Microcontroller (how to fix)
HTML-код
- Опубликовано: 5 авг 2024
- Purchase my new book: Arm Microcontroller Programming and Circuit Building Volume 1
amzn.to/3LFRaU5
I screwed up! OR DID I?!? I bricked my ARM Microcontroller. What do I do now? Watch the video and find out.
Links to the software:
STM32CubeIDE: www.st.com/en/development-too...
STM Studio: www.st.com/en/development-too...
STM32CubeMonitor: www.st.com/en/development-too...
Parts you will need in your prototyping environment:
Kits to get you up to speed quickly:
newbiehack.com/Categories/ARM
If you already have the microcontroller, here are some breakout boards to use:
64 pin - amzn.to/3rUXeiq
48 pin and others - amzn.to/3IVkC6D
STM-Link V2 Programmer:
newbiehack.com/categories/new...
amzn.to/3IIZlgj
Prototyping Breadboards:
newbiehack.com/categories/new...
amzn.to/3o2Nh1g
Resistor Assortment Kit:
amzn.to/3H4R3ii
Solid core hook-up wire 22 AWG:
amzn.to/3IDGinA
amzn.to/3g5TKUJ
LEDs and Displays:
newbiehack.com/Categories/LCD...
amzn.to/3Az1zf7
Trimmer potentiometers:
newbiehack.com/Categories/Pot...
amzn.to/3H6q067
The Dynamixel servo I will be using in the USART videos:
amzn.to/35s3qHl
Microfarad Capacitor Assortment:
amzn.to/32BIX1G
Capacitors on Newbiehack.com:
newbiehack.com/Categories/cap...
Electrolytic Capacitor Assortment:
amzn.to/33TtLxt
The cheap oscilloscope that I use (because it's cheap and will work all of the projects in these tutorials): amzn.to/2rSHnBa
A better oscilloscope and the one I would recommend: amzn.to/2qizK5M
The brand of the multimeter that I use and the one I recommend: amzn.to/2qicUez 
Наука
Man you are amazing , You are the reason i can program microcontrollers ,I am for ever grateful to you, thank for sharing this information
Of course. You are very welcome.
You have some nice videos on your channel. I subscribed.
Allright, I ordered the book and the kit. Looking forward to digging in!
Nice! Thank you!!
Great video Patrick, heads up if you connected the RESET signal from the ST-LINK to the MCU you should be able to avoid the bricking issue in the first place and also wouldn't have to fiddle with the resistor/jumper to unbrick the MCU. The main reason it's acting bricked is because the ST-LINK can't reset the MCU (because SWD has failed & you don't have connection to RESET pin).
It happens!
Thank you very useful information.
You're welcome. Thanks for watching.
Great video showing your troubles switching clocks, thanks! I can offer a couple of hints that might help. I was not able to read your startup code from the video (too blurry) but the process of switching the MCU core from in internal clock to external PLL derived clock involves a few steps. CubeMX generated code will do this correctly, but basically you need to first enable the HSE oscillator first, set your PLL factors appropriately (CubeMX will help with that) and then enable the PLL. Once that’s done you need to *wait* for the PLL Locked bit to be set (it’s a read-only bit). You said that you “locked it” but what you really need to do is *wait* for the PLL to tell you it’s locked before you can finally switch to the PLL clock source. Wait for the lock bit to indicate the PLL is locked, then switch to the PLL source. If you try to switch to the PLL source before it’s locked the MCU will go into the woods, so to speak.
Wow, thanks for the advice. Yes, I did wait for the PLL to be locked before I switched over to the PLLCLK. However, I did not enable the HSE oscillator first. That seems odd that I would need to enable the HSE oscillator. This is with my manual register level code.
I still got the same issue with the autogenerated code, but I did not enable the HSE there either. I didn't know there was a way to enable the HSE without using an external oscillator.
I greatly appreciate the guidance.
@@PatrickHoodDaniel Yes, the HSE is not enabled by default (to save power I guess). The HSE *is* the external oscillator, you need to enable it explicitly because not all boards have it :(
@@waymamma Excellent. May I mention your advice and your comment in my next video?
@@PatrickHoodDaniel I’m glad I could be of some help, been down that road before and it can be frustrating. Sure of course, you can quote me on anything I write :)
I know your video title isn't meant to be click bait, but technically you haven't really bricked your MCU or board by what you did. Bricking IMO means you've damaged the board or a chip on it by corrupting the program(s) to a point that you can't recover it with the tools you have. Here in this video I think you've just got a program with a bug in the startup code, so it doesn't run ;) Very small point, but I thought I'd mention it! Again, great video.
Regarding the ST-Link, I woulnt trust the markings on the case. I've had problems before with that. The solution is to open it up and look at the silkscreen on the board
Thanks for the info. I have not noticed any issues with the ones we used and provided in the past. I do know that is true for other devices; however.
You should really invest in a genuine stlink. It is worth the money and it contains output protection so that it's harder to break it. There is even an isolated version with optocoupled signals.
I appreciate that suggestion. I have one. I just don't use it since there is no need as my st-link clone does exactly what I want it to do. The ST-Link wasn't the problem in this video, it was my code (or the library I was using). I assume you watched the video all the way through. STMicro doesn't make money from selling ST-Links, they make money selling the MCU and other semiconductors, and I make videos on how to use their MCUs, and this is a service to them and a benefit to my subscribers. If I can provide a decent, low-cost alternative to get into learning ARM and STM32 chips, this is how I will do it as I really enjoy doing it this way.
@@PatrickHoodDaniel Yes ofc I have watched your video all the way through - quality content as always. And as for the stlink affordability, I got another one for a price of just two stm32l4 micros that I use in my latest project from farnell so I would say it definitely is hobbyist friendly. It is true that the difference between the clones and the genuine one is rarely justifiable for average hobbyist, but in the industry for instance you can use all sorts of features like enhanced bootloader schemes and most importantly mcu flashing automation - thing that does not work on my stlink clones, as I'm not able to update its firmware anymore. I was even able to embed the flash programming utility into my custom pc application for assembled pcb testing.
@@Acky0078 That is justifiable, if needed. I just don't need that functionality yet. When I do, I will definitely be putting it in my videos. I appreciate you going into detail.
I toasted my laptop by shorting the 5V and GND of my ST-Link V2. Other than carefully inspecting my circuit, are there measures I can take to prevent this from happening again? Is there a way to flash the microcontroller without plugging the ST-Link directly into my computer? Should I use a secondary laptop/pc to program microcontrollers? Is it common practice to add a fuse in the circuit?
Thanks for the awesome videos, I just bought your book :)
Your original thumbnail seemed fine.
Thanks!
I have about 15 hardware designs using STM32F103s. Every once is awhile they seem to lose their identification, stlink can't read the CPU ID. In this case, you have to 'unlock' it. I'm using openocd with gcc on linux. Here are the commands I use to unlock my F103 designs.
Here's a bash script I use to unlock
#!/bin/bash
echo "hold reset"
sleep 2
openocd -f interface/stlink.cfg -f target/stm32f1x.cfg -c "init;reset halt;stm32f1x unlock 0;reset halt;exit"
st-info --probe
If your full erase doesn't work, search around for 'unlock'. Your full erase might unlock the CPU. Thanks for the video.
@@CraigHollabaugh Thanks. Done.
those clones stm32 programmers are not the best. they work but can have some problems some times.
For the PLL. read the datasheet! some registers can only accept a sertand value due to internal state that need to work in between sertend frequencies. if those intermidiate stage are outside of there working area the PLL wil never beable to lock and keep oscillating outside there working range. so calculate what the frequencys are on over multiplication or division.
I had a problem with this too. the stm32 tool does not check for those specifications!
Thanks. I programmed useing the same code on the same MCU 4 years ago (as mentioned in this video) and worked flawlessly. The only difference was the IDE and the STM/HAL libraries. Regarding datasheets, I memorize those things, but I will check to see what I may be doing wrong.
On this ARM2 Series I do not see a pull-up or pull-down resistor on the Data & Clock lines. I wonder why?
It's not needed. I explain that they are not necessary in the previous ARM series. There are internal resistors used.
I'm wondering if you have the same problem with other library for example libopencm3?!
I am going to try the GNU libraries I had before many years ago.
Great Video! I bet you violate / exceed the access speed of your chips Flash access time! In concern of your issue to brick the uC everytime when you drive the clock via the PLL I have an hint: Did you checked to configure the Chips Flashcontroller to let it insert sufficient Waitstates for the Flash accesses? It is vital to configure it _before_ you call the code that switches over to the faster clock. Keep in mind that accesses in Flash are relatively slow for these uC (~10-20 MHz (refer the uCs Datasheet AC characteristics for details))...
So setting the systemcotroller to perform sufficient Waitstates is vital! Hope this helps... Best - Peter -
You should watchthe next video on setting the 48mhz. The pll requires the VDDa and the VSSa power domain.
@@PatrickHoodDaniel: Oh interesting! Thank you! :-)
It looks like the debug interface is not set properly to serial wire in the device configuration which leads to the target not responding message.
It was the use of the PLLCLK and not powering the VDDa and VSSa.
Never had problems like this with STM UCs... but i always use External 8MHz Crystal....
I have a few 16 mhz crystals in stock. I will be putting that on in the next video.
God i remember bricking my atmel chips & not beeing able to reset it ... very frustrating
Yes, once you determine why, and how to remedy, everything is great. It is really easy to get out of a jam with the STM MCU and the tools available.
By looking at your great video it remembers me I ever wonder if it's possible to retreive the program that was flashed into a microcontroller. I came to the conclusion that it's kind of forbiden but what if you install a porgram in your chip and want later on to upgrade it but forgot what version you put on it. Is there any way to get back your program by using STLINK utility app and then look at the code?
PS: I'm not a hacker :)
When you connect the MCU using the ST Link Utility, you get access to the contents of the memory. It is in HEX form and you would need a dissassembler, but I don't see why not. I haven't done it and I probably won't since I can write the program myself pretty easily and my subscribers can also, so it is probably too much trouble to try to determine how an internal program works rather than just writing the simple code yourself. It is an interesting thought anyway.
@@PatrickHoodDaniel Just to mention that I'm one of your subscribers and bought your book... :) Great book! (importation taxe is a pain on amazon though...)
Regarding my comment It was just a thought when I made an arduino program for a board that I had made and wanted to upgrade later on but did not know what version I put in.
Eager to watch what's next :)
wait about 2 seconds after erasing then pull resistor. Couldn't get it at first.
Think I will stick to Microchip pics they are simpler
Really. Changing registers are the same. Can you give me an example how they are different?
That is, until you encounter the segmented memory model. High level programming on a PIC is definitely not any simpler than ARM.
I'm not sure if you've made any progress on this 'brick' problem as you call it, but I have a couple of ideas in case you're still stuck.
For one thing in your startup code (I was finally able to read it!) I would recommend not fiddling with the RCC_CFGR_SW bits by trying to switch to the HSI. You're already running off the HSI at this point (assuming no other startup code has run elsewhere) so trying to switch to the HSI as your source is redundant. Best to leave those bits alone unless you actually need to perform a clock source switch. If you feel the need to change the RCC_CFGR_SW bits then you should at least ensure which clock source you're running from first, before you change those bits (just good practice).
The other thing that looks a bit weird to me is that your ST-Link connections seem to be missing the RESET line to the target. I see only four wires (power, ground, and the two SWD pins) but no RESET. Without the RESET line ST-Link will not be able to control the target and this will no doubt cause you lots of grief. You should NEVER need to fuddle with the MCU's RESET line directly in any way. It's hard to tell from your video what the exact steps you go through during programming, but I have to ask the basic question "what makes you think you've actually 'bricked' anything?" There is no visual indication I can see that any code is running on the target like an LED blinking. Are you thinking that something has gone wrong because of the "Target not responding" message? This may be simply caused by a missing RESET line to the debugger.
Lastly, you've not set up your PLL multiplier properly (line 96) as you are turning off the MUL12 bits instead of turning them on. This isn't the cause of your problems, but it looks like a mistake to me.
Good luck!
It was completely solved. I guess you didn't look at my latest posts. ruclips.net/user/PatrickHoodDanielcommunity
@@PatrickHoodDaniel Nope, those posts are not on my feed.
@@waymamma Ah man, that's not good. You are missing out on the polls that I put up to get feedback. Did you see the post through the link. The problem was that I did not power the VDDA as that is the PLL's power domain. I will be explaining that in-depth in the next video. I noticed the video that I uploaded from 4 years ago had those two pins (VSSA and VDDA) connected to power.
The stlink utility has been superseded by the cube programmer app
Interesting. I will take a look at the application and make a video on using it, especially on getting out of a jam. Funny, the webpage of the ST-Link utility says it is replaced by the cube programmer app. Ha! I should have been more observant!
@@PatrickHoodDaniel I'm still dead in the water with the oem st-link and your newbie hack M0 breakout board, it doesn't see the target
@@embededfabrication4482 would you like me to send you another board?
@@PatrickHoodDaniel no, just need to figure out the settings to talk to the M0 chip with the oem stlink. it shouldn't be this hard.....
@@embededfabrication4482 No, it absolutely should not be that hard. I have faced a few barriers, but once I was able to resolve them, I had no problems going forward. Most of the time, it is not what you expect. For instance, in my recent issues with the 48Mhz trials, I was certain it was the st-link causing the problem. The messages that the compiler give is always the same can't connect to the target, or the st-link is not recognized (or something thereabouts). Once I determined that it wasn't the st-link, I said to m myself, it must be a bad chip, so I replaced the chips, and the same thing happened. In the end, I did not know that the PLL required the VDDA and VSSA to be connected (evidenced in the video that I made 4 years ago). In the past, I mistakenly programmed the SWDIO and the SWCLK to be output for testing, a bad idea, and I needed to do the same process to erase the chip, but the trails before I knew the problem... long and arduous!
I can say one thing, it is usually the code or a loose connection.