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

[bobcov]

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?

[STOne-32]

Dear @bobcov ,

Can you share a picture of the top marking on the device.

if flashing is correct , then you can make a run and see the PC - Program counter ? Versus a good device ( multimeter ) running fine .

Ciao

STOne-32 

[bobcov]

Hi, hard to get a good picture, but I hope this is good enough. A friend did the soldering. Maybe what I am seeing is a result of something bridged? I will look under a USB magnifier scope today, but if I remember correctly, I checked for the basic fault condition after the connections were attached but before I tried the first flash. I don't think it is something related to the connections, but it is possible. I'll ask about the program counter with the guy who did the soldering. What program do I need for this step? I can use Ubuntu or Windows 10.   Thank you very much for your input.

-B

[BarryWhit]

>  This is also the case if I flash the entire known good file with its included calibration section instead of my saved calibration data

 

Did you dump the original flash contents before overwriting it? if so, try re-flashing that and see if you're at least back you started. Then report back.

 

Can you be sure that the manufacturer didn't have multiple revisions in circulation, which may not be entirely firmware-compatible? for example, there might be (I'm just guessing here) some kind of ID mechanism (resistors, ID chip, small EEPROM) on the PCB which the flash checks before booting.

 

btw, ST Link Utility has been EOL for a long time, superseded by STM32CubeProgrammer (GUI or cli).

[bobcov]

Hi,

     The github instructions specified using a modified version of OpenOCD to dump and save the firmware.  I did that as the first step and then tried reloading that at later stages when the patched firmware didn't work.  No change in the behavior. The OEM board (Voltcraft VC7055 is the product) has the same markings as the original (Owon XDM2041), and the firmware is supposed to be compatible. Loading the original back in did not get me back to where I started, so I don't think this is the issue. However, there is another project speciically for the Voltcraft, but I can't compile it because of a tool it requires which I don't have which apparently only runs under MacOS.  Working on that to get it done on other equipment so that I can try that other firmware. I've asked the author of that project for .bin file. I can try flashing with STM32Cube program. I have it, but unlike STM32 ST Link Utility, it defaults to all of the memory protected and I am afraid to uncheck all the memory protection because I don't know if I can damage something that way or if it is perfectly okay. I don't know if it is possible to overwrite something such that the processor no longer responds to the Cube or ST Link programs.

Thanks for your help!

-Bob

 

[Tesla DeLorean]

Do you let the BOOTx pins float?

[bobcov]

Hi,

    I used a jumper we added to bring BOOT0 high so that it could be flashed.  After flashing, the jumper was removed and then the board was powered up with 5 volts.  Please let me know if there are more BOOTx pins I should be manipulating.

Thanks!

 

-Bob

[Tesla DeLorean]

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.

[BarryWhit]

If flashing the original firmware leaves you in the same state, then obviously the (current) issue is not with the modified firmware. A solder bridge, or some damage, seems more likely. Also, keeping your mod wires connected while booting might affect the circuit - it depends on what you connected. Connecting something to the SWD pins shouldn't usually matter, but if you put something on the reset pin or if your ST-LINK clone is pushing power on the voltage rails - that could be an issue.

[bobcov]

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

[MM..1]

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.

[STOne-32]

Hi @bobcov ,

 

I encourage you to get an STM32F103CBT6 from STMicroelectronics , the part shown is from GD and is not our STM32F103 :

You can find it here Buy STM32F103CBT6TR - ST Online Store  or any official distributor .

Hope it helps you.

Ciao

STOne-32.

[BarryWhit]

 I also encourage you to use original ST parts, but I would strongly discourage you from replacing the part inside a board you are repairing with an original but essentially different part number from ST. They are meant to be compatible of course, but this is never 100%. Software developed and tested on one may exhibit issues if you try to run it on the other. This could be due to silicone differences, or even an explicit check of the vendor ID in the firmware.

Moreover, this particular Gigadevice chip was marketed as STM32F103 compatible but with a significantly higher max clock frequency. If the manufacturer made use of this difference, it would be "not good (TM)" to sub an original STM32F103 for it.

 

 

[bobcov]

Still waiting to hear the results of the friend of a friend who took over this project.  I finally got original firmware from the manufacturer and I find that it is not 128k as all of the documents had said.  It is 110.6k. Just forwarded the file today to the guy working on the meter.

[BarryWhit]

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.

[BarryWhit]

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.

[bobcov]

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.

[BarryWhit]

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).

 

[bobcov]

Hi,

   Dongle was never powered when 5v was applied to the board.

   Super advice on what to check and how to check it. The good news is that I have until Thursday to try to do this.

   The "bad" news is that a friend who owns an electronics shop won't sell me a replacement processor. He says I don't have the equipment to do this properly, so he's ordered the processor and will have one of his people do the replacement and the flash. I will meet him on Friday and handover the board.  Because it's a home office, I won't get to watch and learn. But I will update as this progresses.

    The firmware is a mystery because the Github project I am following explicitly says to extract the last 2K of the downloaded "corrupt" firmware, because it has calibration data unique to the meter.  Okay, so I did that and joined it to the original firmware minus the last 2k. But when things weren't working, I extracted the last 2k of the official firmware file and discovered the MD5 sum for both 2k files was identical. This makes me wonder what else might be wrong with this project if it has me spending time extracting stuff that is identical. I'm going to try to get a 2nd firmware from another guy who has a project for this meter.

 

   Thanks again for all your help and suggestions.

 

-B

   

[BarryWhit]

@Lina_DABASINSKAITE this is ridiculous. I can (sort of) understand censoring certain high-octane words, but censoring the word ***  (f-o-o-l) is positively Victorian. We're not living in a 19th century puritan society, and this level of incongruous intervention in members' communications is far more offensive than the "bad" words being censored.