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 

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

[Tesla DeLorean]

Do you let the BOOTx pins float?

[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

[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

[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

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

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