Author Topic: how to rescue a bricked STM32F05 given suspected raw firmware image (Read 2168 times)

drDuesentrieb · « **on:** December 29, 2023, 03:29:17 pm »

Hello,

a wireless firmware update of my Skywatcher AZ-GTI (https://www.skywatcher.com/product/az-gti-mount/) went wrong and the unit seems to be dead.
Web research shows that there is a change to connect via serial port when the unit is stuck in update mode (flashing LED). As my mount does not even flash the LED I had little hope which was confirmed after trying this.

So I went down one level, opening the thing up to find a STM32F051R8T6 on the PCB. As I am playing around with STM32F4 anyway, I should be able to program the MCU directly if the interface is not disabled.

The manufacturer provides a .mcf file for their firmware update tools.
Is there any chance to identify what type of file this is and how to make this compatible e.g. with the STM32 Cube Programmer?

mcf-file is attached.
Source here:
https://www.skywatcher.com/download/software/motor-control-firmware/
Firmware: AZGTi Mount, Right Arm, AZ/EQ Dual Mode, Version 3.40
https://inter-static.skywatcher.com/downloads/azgti_motor_controller_firmware_right_arm_0340.zip

coromonadalix · « **Reply #1 on:** December 29, 2023, 04:22:13 pm »

maybe some hints here ?
https://www.cloudynights.com/topic/861631-az-gti-firmware-update-problem-and-solution/

https://www.astropills.com/blog/how-to-update-your-sky-watcher-az-gti-firmware

drDuesentrieb · « **Reply #2 on:** December 29, 2023, 06:33:16 pm »

Thank you. Already gone through the "usual" channels without any luck.

magic · « **Reply #3 on:** December 29, 2023, 07:45:02 pm »

Since the file is exactly 64KB in size and the MCU has the same amount of flash (if I found the right specs table, I'm not familiar with STM32 myself) it's possible that you are simply meant to write the file to flash byte by byte. There are some ASCII strings in the file so it doesn't even seem encrypted.

Do you have some sacrificial dev board to try it with?

drDuesentrieb · « **Reply #4 on:** December 30, 2023, 11:55:29 am »

I do not have a sacrificial board at hand. Therefore I am worried making things worse.
That it is 64 kB matching the flash size is an interesting point.

However, if I am importing the file to the STM Cube Programmer, it does not show me the actual content of the file.
Also "size" is shown as 0.
Screenshot attached.
On the left side what I am used to see, on the right side when I change the .mcf to .bin an open it. Does not fill me with confidence, but I also don't know what to expect at this point.

Any ideas?

coromonadalix · « **Reply #5 on:** December 30, 2023, 12:09:31 pm »

send the company an email about your problem

they are the ones who create updates, they surely know ho to deal with failed upgrades, unless they try to rip you off ?

mikerj · « **Reply #6 on:** December 30, 2023, 12:10:05 pm »

I wouldn't trust the STM32 tools to display anything useful. Open the file in a hex editor, e.g. https://hexed.it/ and you will see that is appears to be a simple binary images as suspected. The first few dozen words are interrupt vectors and the addresses look reasonable.

magic · « **Reply #7 on:** December 30, 2023, 01:24:10 pm »

It seems you programmer software expects ELF format. I wonder if it could be as simple as packing the firmware blob as a single .data section, i.e.

Code: [Select]

objcopy -I binary -O elf32-littlearm -B arm AZGTi_motor_controller_firmware_right_arm_0340.MCF AZGTi_motor_controller_firmware_right_arm_0340.elf

What's the "Device Memory" tab? Are you able to read the contents of the chip?

fzabkar · « **Reply #8 on:** December 30, 2023, 03:55:48 pm »

It's 32-bit, but the endianness needs to be reversed (see attachment).

Code: [Select]

Offset(h) 00       04       08       0C

00000000  00200020 55010008 09100008 11100008
00000010  00000000 00000000 00000000 00000000
00000020  00000000 00000000 00000000 19100008
00000030  00000000 00000000 21100008 29100008
00000040  31100008 39100008 41100008 49100008
00000050  51100008 59100008 61100008 69100008
00000060  71100008 79100008 81100008 89100008

Edit:

I'm confused.

The hex data and the ASCII characters in your screenshot have opposite endianness.

fzabkar · « **Reply #9 on:** December 30, 2023, 04:49:14 pm »

Quote from: magic on December 30, 2023, 01:24:10 pm

It seems you programmer software expects ELF format.

ELF files have an 0x7F "ELF" signature. :-?

https://en.wikipedia.org/wiki/Executable_and_Linkable_Format

coromonadalix · « **Reply #10 on:** December 30, 2023, 04:56:10 pm »

nah not this one, its a renamed file for their use, and they may have played tricks in it ... all to protect their ip

we do a name change in one of our windows CE6 module, but renamed to something else, just to confuse people loll the upgrade only accept the renamed file ...

magic · « **Reply #11 on:** December 30, 2023, 08:44:10 pm »

IMO this file is simply an exact image of flash contents, no compression, no byte swaps, no encryption, no obfuscation, no nothing, and needs to be written to device program memory verbatim. Reasons:
1. Size is precisely 65536 bytes.
2. The file contains several ASCII strings including IP addresses which make perfect sense and aren't mangled in any way.
3. Disassembly (objdump -b binary -m arm --disassembler-options=force-thumb -D AZGTi_motor_controller_firmware_right_arm_0340.MCF) produces output that may be reasonable code, for example I see many instances of cmp followed by conditional branches. Although take this with a grain of salt, I have no real familiarity with ARM assembly.

My advice:
1. Go back to the first post, change the title to "how to rescue a bricked STM32whatever given suspected raw firmware image".
2. Move this thread (find a button at the bottom of the page) to the "microcontrollers" section.

Rationale: this is a highly specific MCU issue, it has little to do with telescopes, everything to do with microcontrollers, you need help of people familiar with STM chips and programmers.

One more important question: are you 100% sure there are no other chips inside and this is the one which you tried to upgrade?

drDuesentrieb · « **Reply #12 on:** January 02, 2024, 07:00:00 pm »

Thank you guys. I will give the manufacturer another week (then two in total) to answer before I operate further on the device.
First call one week ago with my local supplier did not bring up my hopes that there will be an answer at all.

@magic: I will follow your advice.

darkspr1te · « **Reply #13 on:** January 03, 2024, 02:40:45 pm »

for shits and giggle i ran this through ghidra and it looks complete, it looks like this is the complete code for the stmf32f051 , it also seems to have a two part loader in case of update failure,

darkspr1te

drDuesentrieb · « **Reply #14 on:** January 04, 2024, 09:36:06 pm »

Moved the topic from "Repair" to "Microcontroller".

I started to play around with the PCB and was able to connect to the MCU via SWD.
Conveniently, there is a pin header with the CLK and DATA pin but I had to connect to the RESET directly at the MCU as well.
Picture: 2024-01-04_01.jpg

The read-out is attached and it looks very similar to the manufacturer's file. At least the first 4 kB. This is the full read-out, the tool gave me.
So, if I do not miss any buttons, 60 kB are missing. Is this some kind of "recovery" mode and the system detected the failed update?
Picture: 2024-01-04_02.jpg
Read-out: firstReadTry_SWD_2024-01-04_01.bin

Good progress so far and I would like to flash the MCU via SWD with the file from the manufacturer (AZGTi_motor_controller_firmware_right_arm_0340.MCF renamed to .bin)
When I open the file with the flash tool, the adresses start with 0 and not as in the read-out with 0x08000000 (Compare 2024-01-04_01.jpg and 2024-01-04_03.jpg).
Do I have to worry about this or does the flash tool do the right thing when I hit the program button?

darkspr1te · « **Reply #15 on:** January 05, 2024, 06:18:13 am »

before you flash it you need to download all of the old firmware, when connected via stm cube programmer , first click connect, after initial connect click size and change from 0x400/0x1000(decimal 4096) to 0x10000 (decimal 65536) and the click on read again. it should now read entire flash and you can save and post that file

darkspr1te

Jeroen3 · « **Reply #16 on:** January 05, 2024, 08:21:44 am »

In your readout the first 0x1000 bytes are there. However the second entry in the vector table references to x1009 which is empty flash.
The code that is there in the first x1000 bytes look like an protocol decoder.

Your readout almost matches the given binary, so I suspect if you use the ST-Link to write the provided binary to 0x08000000 (flash) the thing will work again.

peter-h · « **Reply #17 on:** January 05, 2024, 02:06:33 pm »

Normally 1st 32 bit word is the SP load and the 2nd 32 bit word is the PC load i.e. the start of the real code. After these two words are the various interrupt vectors.

drDuesentrieb · « **Reply #18 on:** January 05, 2024, 10:15:43 pm »

Gentlemen, success.

The manufacturer's file could be flashed to the MCU and the telescope mount is working again. Thank you all for your support.

For completeness: @darkspr1te: You were correct, I missed one "0" so I only read the first 4 kB. However, reading the complete 64 kB showed that the remaining flash was empty (file attached). So the failed update might have erased the whole flash and aborted after the first section.

Thanks again, eventually an easy fix but very ensuring with all your input.


EEVblog Main Site	EEVblog on Youtube	EEVblog on Twitter	EEVblog on Facebook	EEVblog on Odysee

Author Topic: how to rescue a bricked STM32F05 given suspected raw firmware image (Read 2168 times)

Share me