2024-08-18 12:01 PM
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?
2024-08-21 11:13 AM
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
2024-08-21 11:36 AM - edited 2024-08-22 06:23 PM
@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.
2024-08-21 11:40 AM - edited 2024-09-02 04:15 AM
@bobcov, I think your friend is doing you a favor by preventing you from further damage (assuming this "friend" isn't gauging you on the repair and parts). With that said, you can buy these chips cheaply on Aliexpress or LCSC. Replacing them is not hard if you have prior experience and basic tools. But you shouldn't practice on a board you care about.
If in-circuit programming facilities are not designed into the board to begin with, it's much safer in many cases to simply remove the chip from the board for reprogramming, and then remount it.
2024-09-02 03:30 AM
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.