compatibility with t3b #4
Comments
|
Well, yes, it would be possible, but I don't own a T3B, so I cannot dump it. |
The firmware update JC_M_T3B_1.14.bin is in the public domain. Is it possible to make the bootloader compatible somehow? I can be a tester, I don't hope for soldering station revival, but at least for people for the future. On the soldering station static voltage killed the MCU. I soldered a new one (GD32f305ret6). By burning your complete firmware, I managed to get the logo to appear, but the station cyclically reboots. I installed the firmware from (t3b), the message "waiting for firmware" appeared in Chinese, but Unknown USB Device. |
Yep, but someone needs to take the time to reverse it ;)
The hardware initialization might be a bit different (mostly GPIO config). However, it might be possible... let's see. I can be a tester, I don't hope for soldering station revival, but at least for people for the future. On the soldering station static voltage killed the MCU. I soldered a new one (GD32f305ret6).
I don't get this. How exactly did you install the T3B firmware? |
|
I tried to create a full T3B image. Can you try this one? |
I tried to build a complete firmware using your script, replacing the firmware update with T3B. After flashing the firmware with ST-Link V2
I tried all the options and combinations.
My friend, you are a genius!!! The T3b station came to life. The Aixun logo appears, after turning the encoder the interface appears for a moment and then it says in Chinese "T210 without tools, insert the required soldering tip" P.S. The stand is plugged in, I have plugged in other working tips. P.S.S. I burned the firmware with ST-LINK v2. P.S.S.S. USB по прежнему "Unknown USB Device." |
Ah, got it. That's basically what I tried. However, I added the correct DRM key for T3B and replaced all T3A identifiers in the bootloader with "T3B". wget https://usr.tnyzeq.icu/~dd/aixun-updates/firmware/JC_M_T3B_1.15.bin
head -c $((0x40000)) /dev/zero | tr '\000' '\377' >"t3b.full"
# bootloader from v1.26 dump
dd if="bin/t3a_dump_cleaned_v1.26.bin" of="t3b.full" bs=1 count=$((0x10000)) conv=notrunc
# replace all T3A strings with T3B
sed -i'' 's/T3A/T3B/g' t3b.full
# main image from update
dd if="JC_M_T3B_1.15.bin" of="t3b.full" bs=1 skip=$((0x100)) seek=$((0x10000)) conv=notrunc
# image header from update
dd if="JC_M_T3B_1.15.bin" of="t3b.full" bs=1 seek=$((0x3f800)) count=$((0x100)) conv=notrunc
# drm magic, extracted from update image
echo -n 'jc__aixun_zxc_t3b_20210805163200' | dd of="t3b.full" bs=1 seek=$((0x3f000)) conv=notrunc
Maybe the Op-Amp was damaged as well?
Hmm, did it work before the damage? |
is in good working condition, no short circuit, output voltage 2.8 V. I will double-check later.
Yes, as a FIDI com port. P.S. After searching, it turns out the 210/245 tips have different pinout and resistance. Perhaps this affects the detection of the tip? |
Ok, good to know
Yeah, right. Handle detection is based on the ID pin (resistor value / con to GND). IIRC the T245 has ID=GND, while 210 has some resistor. Detection of the tip being inserted is done by checking the temperature value (via OpAmp). If it's out of range, the firmware assumes a missing tip. So, either there is more damage or the firmware is relying on some GPIO initialization the bootloader is doing (which is now missing bc it's the T3A bootloader now). Maybe ask in the EEVBlog forum if someone can dump a T3B? |
|
Did you get your replacement board? Would be great to have a T3B dump as well :-) |
Yes! But! The motherboard arrived without firmware..... https://youtu.be/B80BxZ6fpog P.S. We are in dialogue with the seller. |
|
OMG unbelievable......... so did you actually try to dump it? or connect via USB? maybe the bootloader is there but just the main firmware missing. You could try to flash that hacked-together image and see if it works on this board. (So we could rule out the hardware issue theory for the other board) |
|
Hi, friend. Finally sent a working board with a flashed microcontroller. But. r0p1.
|
|
p.s. I am not very familiar with OpenOCD. p.s. The previous microcontroller and the one sent are blank. firmware is readable. The last one, however, writes an error. LOG> Open On-Chip Debugger 0.12.0 |
|
Log dump of the previous microcontroller. Open On-Chip Debugger 0.12.0 and the firmware appears in the home folder |
|
p.s. my cmd to dump CMD
openocd -d2 -f C:\Users%UserName%\AppData\Roaming\xPacks@xpack-dev-tools\openocd\0.12.0-2.1.content\openocd\scripts\interface\stlink.cfg -c "set CPUTAPID 0x2ba01477" -f C:\Users%UserName%\AppData\Roaming\xPacks@xpack-dev-tools\openocd\0.12.0-2.1.content\openocd\scripts\target\stm32f1x.cfg -c "init; reset halt; flash read_bank 0 firmware_dump2.bin 0 0x40000; exit" |
|
r0p1 is just the chip revision. But the read error indicates they started using RDP..... I will come up with a non-destructive solution fot dumping.... |
Sorry, got the chip revision and security level mixed up..... As I understand, if debugging is available, it is RDP level 1? |
|
at RDP1 debugging is available but any flash access is blocked. RDP2 locks the debugging interface as well. There are a few options for GD32F303:
I need to do some tests on my T3A... |
|
I managed to implement a dumper firmware for T3A :D I need to modify it a bit for T3B now ;-) Update: finally... you can follow these instructions for bootloader dumping :-) https://github.com/c0d3z3r0/aixun_t3a_rev/?tab=readme-ov-file#t3b-bootloader-dumping |
Python scripts don't work in Windows OS, instead of getting the port I manually wrote "COM4". Loading the firmware works, but when I try to do a dump, an empty fw.bin file is created. I'll try again later on Linux. cmd output>
E:\pc\desktop\t3b\aixun_t3x_updater>py -3.8 t3xupdate.py fw_t3b_patched.bin
INFO: Update: T3B v1.15 (184656 bytes)
INFO: Enter bootloader...
INFO: BL version: v0.04
Send update...0%...1%...2%...3%...4%...5%...6%...7%...8%...9%...11%...12%...13%...14%...15%...16%...
17%...18%...19%...21%...22%...23%...24%...25%...26%...27%...28%...29%...31%...32%...33%...34%...
35%...36%...37%...38%...39%...41%...42%...43%...44%...45%...46%...47%...48%...49%...51%...52%...
53%...54%...55%...56%...57%...58%...59%...60%...62%...63%...64%...65%...66%...67%...68%...69%...
70%...72%...73%...74%...75%...76%...77%...78%...79%...80%...82%...83%...84%...85%...86%...87%...
88%...89%...90%...92%...93%...94%...95%...96%...97%...98%...99%...100%
INFO: Update successful!
cmd output>
E:\pc\desktop\t3b\aixun_t3x_updater\aixun_t3a_rev\t3x_dumper>py -3.8 dump_fw.py
INFO: Trying to dump firmware...
INFO: Firmware written to fw.bin |
|
Hmm, didn't test on Windoze, will try... |
|
I've just pushed a compatibility fix for Windows. Both dumper and updater work in Windows 11 for me. Can you test it again, please? Regarding the dump. Does the T3B still behave correctly after dumping? Can you push buttons, enter menu, does the time count up? |
Yes. I'll do this now in Windows and also, just in case, I've put together a portable build of Linux. I want to double-check on Linux! |
t3xupdate.py works well. was 1.14. after fw_t3b_patched.bin updated to 1.15. the temperature is displayed correctly. buttons etc work. I immediately run dump_fw.py. There are no errors, only an empty bin file. |
|
Hm, ok, then let's do some tests... what's the output of this modified script? |
E:\pc\desktop\t3b\t3x_dumper>py -3.8 dump_fw_beta.py
INFO: Trying to dump firmware...
DEBUG: TX: b'JC_identity'
DEBUG: RX: b'JC_User'
DEBUG: TX: b'JC_version'
DEBUG: RX: b'JC_M_T3B_version1.15'
INFO: Firmware written to fw.binempty fw.bin |
|
Ok, looks good. Next one: |
stuck on E:\pc\desktop\t3b\t3x_dumper>py -3.8 dump_fw_beta1.py
INFO: Trying to dump firmware...
DEBUG: TX: b'JC_identity'
DEBUG: RX: b'JC_User'
DEBUG: TX: b'JC_version'
DEBUG: RX: b'JC_M_T3B_version1.15'have to wait long? |
|
Interesting... that means for some reason the firmware doesn't send data with the injected command. Let's see if we can receive a simple string. On my T3A it works. |
E:\pc\desktop\t3b\t3x_dumper>py -3.8 dump_fw_test.py
INFO: Trying to dump firmware...
DEBUG: TX: b'JC_identity'
DEBUG: RX: b'JC_User'
DEBUG: TX: b'JC_version'
DEBUG: RX: b'JC_M_T3B_version1.15'
DEBUG: TX: b'dump'
DEBUG: RX: b''and just hangs and does nothing |
no, ...98%...99%...100% . single beep . INFO: Update successful! p.s. maybe put the whole station together? I'm flashing it disassembled. only mainboard + display. |
|
You need to rum dump_fw.py to trigger the double beep (if it works). Mainboard + display is enough |
E:\pc\desktop\t3b\t3x_dumper>py -3.8 dump_fw.py
INFO: Trying to dump firmware...
INFO: Firmware written to fw.binno beep, silents, only crated empty fw.bin |
|
Ok, then the patch still doesn't work... I'll go different approach now... reduce jumps and just replace command... give me a few minutes |
|
Next try: |
ja ja!!!! fw.bin 256kb |
|
hah, niiiiiice! |
I hope this is a complete dump with a bootloader. |
|
Yes, it is :-) I'm working on preparing a flashable image |
|
Try this on your dead boards (via SWD ofc) |
E:\pc\desktop\t3b\t3x_updater>openocd -f stlink.cfg -c "set CPUTAPID 0x2ba01477" -f stm32f1x.cfg -c "init; reset halt; flash write_image erase JC_M_T3B_v1.15.full.bin 0x08000000; reset run; exit"
Open On-Chip Debugger 0.12.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
0x2ba01477
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : clock speed 1000 kHz
Info : STLINK V2J43S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.226877
Info : [stm32f1x.cpu] Cortex-M4 r0p1 processor detected
Info : [stm32f1x.cpu] target has 6 breakpoints, 4 watchpoints
Info : starting gdb server for stm32f1x.cpu on 3333
Info : Listening on port 3333 for gdb connections
[stm32f1x.cpu] halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
Info : device id = 0x21040414
Warn : STM32 flash size failed, probe inaccurate - assuming 512k flash
Info : flash size = 512 KiByes!!!!! green mainboard and black mainboard work!!! but, green (305) usb not work (code43) |
|
What's the version/revision of the boards? Should be printed somewhere |
|
Oh wait, I just read your earlier comments. All boards were F303 originally and your soldered that F305, right? |
no no The green board was originally 305. I replaced it with a new 305 chip. This is where this quest to find a bootloader began! The seller was recommended on the forum. I ordered from him, they already sent me a black motherboard, 303. It turned out to be empty. The seller agreed to send it again, sent it in JCID packaging. and lo and behold. working. same black, and 303 chip |
|
|
Ah, got it, thanks. Hm, then there might be some tiny difference with that F305... but how did it ever work then? Weird. Curious, did you ever try to flash that hacked T3A bootloader on one of the F303? :D #4 (comment) |
no. I'm going to try now! |
|
I had another look at the GD32F30x datasheet (https://www.gigadevice.com.cn/Public/Uploads/uploadfile/files/20230228/GD32F30x_User_Manual_EN_Rev2.9.pdf). I think the relevant difference here is:
Now I wonder, how this board ever worked because the firmware only implements USBD. |
lol. usb black board work it with bootloader from t3a |
Awesome 🤣 🥳 |
|
So, the question remains open, how the green board got it's F305. Maybe it was a "repaired" board? Maybe it was a bad clone? Who knows.... |
Apparently, the bootloader of the Green motherboard is different from the black motherboard. |
|
But not only bootloader must implement USB, firmware as well. So both must be different |
|
Oh, well, I should have read my own notes \o/
That applies to T3B(S) as well... are you sure you bought yours as T3B and not T3BS? Do you have that top-mounted handle holder? https://www.aixuntech.com/newsinfo/aixun-new-product-launch-t3bs-allinone-100w-soldering-station/ |
I bought it before t3bs was released. feb 2022 |
|
Oh ok... then I have no idea. I guess your best option is just replacing the F305 with a F303 |
my friend. I have flashed your full dump to a clean black motherboard. The soldering station is assembled and already working like new, it has been many tests! I kept the green motherboard as a learning material. p.s. and kept the locked working motherboard in case something burns out. thanks a lot! |
|
Sure, it was just a suggestion :-) |
|
hats off to you guys :) |
is it possible to do the same for T3B? After flashing this dump onto t3B, the USB descriptor error occurred. It is not possible to update the firmware with the standard utility.
The text was updated successfully, but these errors were encountered: