cancel
Showing results for 
Search instead for 
Did you mean: 

What could I be doing wrong that makes known good firmware not boot?

bobcov
Associate II

I’m a newbie when it comes to flashing microprocessors. I am wondering if anyone can deduce what I may be doing wrong given the following set of facts.
1. The device I was trying to repair had the symptom of halting after the progress bar instead of booting into its multi-meter software on power-up. This is a well-known fault for this particular meter and there was a set of instructions for saving the calibration from the existing firmware, merging it with a known good firmware and then reflashing.
2. After flashing, I no longer get the progress bar on power up. I get random pixels and nothing more, even though the STM32 ST Link Utility verifies the firmware flashed matches the firmware file. This is also the case if I flash the entire known good file with its included calibration section instead of my saved calibration data. It’s a128K file, the flash starts at 0x08000000.
3. Given that STM32 ST Link Utility says what is flashed matches the source file, what else could I have done wrong that would prevent the firmware from running? nRST_STOP and STDBY and WDG_SW are checked in option bytes. After flashing, I remove the pin holding BOOT0 high. STM32 ST Link Utility sees the processor as STM32F10xx medium density with device ID 0x410. It’s a GigaDevices GDF103xx. I just get the feeling that I am not loading this firmware properly. Very much stumped. Any ideas?

23 REPLIES 23

I think this is a strong possibility. I will look into removing the various attachments and checking closely to see if there are any pins bridged.  If that goes nowhere, then I think i will look into a replacement processor of the same type. I wish I could remember for certain whether or not I got the boot progress bar after the wires were attached, but before the flash.  I'll have to ask the guy who was with me when we started this.  As far as flashing goes, nobody seems to have flagged anything wrong with that end of it, so I will assume the flash is good and that something else has gone south or the wires are affecting the circuit.

I also would like to take a moment to express my thanks and gratitude for the way people have come forward to attempt to help a guy who knows very little.  Lots of patience and grace shown here in this forum, something which reflects a community of quality folks.  Thanks! Of course, I'll keep working on this and when I find a resolution, I'll speak about it here.

 

-Bob

Ok, and without the jumper is it PULLED-LOW, or just FLOATS ?? Floating can result in unexpected behaviour.

Sorry not familiar with the schematic / board.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
BarryWhit
Senior III

DeLorean, he's basically modding a commercial product which presumably has been working in the field for a while. 

It's always good to double-check BOOT0, especially if you fooled around with it, but it most likely has a pull-down on the board.

- If someone's post helped resolve your issue, please thank them by clicking "Accept as Solution".
- Please post an update with details once you've solved your issue. Your experience may help others.
BarryWhit
Senior III

Oh hell, Voltcraft is a german company. Trust me, they did NOT forget to add a pull-down. And if this multimeter displays a progress bar during boot it's probably one of their fancy models, likely not a cheap piece of junk.

- If someone's post helped resolve your issue, please thank them by clicking "Accept as Solution".
- Please post an update with details once you've solved your issue. Your experience may help others.

Hi Bob, before replace check actual state . You repair multimeter then you i hope know how use and measure voltage on pins , short circuits etc. And for what you set BOOT0 pin, normal situation dont require it.

How can I tell if it is being pulled low or not? I would assume that the reason I had to pull it high to flash was because it was normally low.  But newbies are in no position to believe in our assumptions.

That may have been the case back in the day, but this particular meter was designed and built by Owon and even has the Owon multimeter XDM2041 markings on the boards. And also, just like Owon, this meter has the known fault of corrupting flash, which is what got me on this adventure.

I disconnected the wires that were direct from the microprocessor and noticed that now when it is powered on, it takes a few seconds before the screen of random pixels appears.  Before this, it was pretty much instant.  Ground, clock, data and 3.3 volts had been connected to the ST Link dongle and a jumper was attached to pull BOOT0 high for flashing. The flashing was done with the board removed from the meter. When the board was powered, the dongle was not plugged in...but...hmmm...the connections were still attached to the dongle. Hmmm..  There are still a few leads attached at points which lead to the microprocessor. I will unplug from the dongle and see if anything changes.

BarryWhit
Senior III

If the dongle was never powered on when the meter was turned on, it should not be the issue. a solder bridge or damaged component is still more likely.

 

 

1. measure resistance between voltage rails and GND.

2. check every pair of adjacent pins (near reworked areas) for shorts, with a multimeter.

3. Note everywhere you see flux reside. Clean the flux residue thoroughly then look at all the solder joins with a microscope or cheap 30-40x loupe. The resistors by the flat printed cable look dodgy from the image, for example. 

4. check whether any chip pins have lifted from their pad while you were applying heat.

 

Visual inspection can uncover obvious solder bridges, but they also play hide-and-seek with you. Measuring continuity with a multi-meter is more ***-proof. thorough cleaning is crucial since the flux goop can hide defects.

 

Before anything else, perform all these steps and thoroughly. Until you do, there's no point in suggesting next steps for general troubleshooting. 

 

> As far as flashing goes, nobody seems to have flagged anything wrong with that end of it, so I will assume the

> flash is good and that something else has gone south or the wires are affecting the circuit.

 

It's up to you, but your patched firmware is an unknown you can eliminate.  If your firmware is the issue, you'll be chasing ghosts forever. If you can't find an electrical issue, I strongly recommend you remove any modded firmware from the equation, since that is something you know changed since the multimeter was functional. That makes it a far more likely cause than a damaged chip. And If you remove the chip, that's also a chance to test it out-of-circuit (you can remount it on a chip blue-pill board, for example).

 

- If someone's post helped resolve your issue, please thank them by clicking "Accept as Solution".
- Please post an update with details once you've solved your issue. Your experience may help others.

As you have the board, you could presumably trace the circuit and make a determination if there was a pull-down resistor associated with this pin.

Was the firmware "known good" for the GigaDevices or STMicro part, not sure they are 100% interchangeable or not

Pulled HIGH in the STM32 sense is that it's using the ROM Boot Loader and not running the FLASH code, running the FLASH code can be problematic if it reconfigures the debug pins (ie PA14, PA15) or put the board into a low power mode where the pins and logic behind them is unpowered and consequently non-functional. The ROM Boot Loader would also permit pushing in firmware updates via USART1 and USB methods.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..