Jabe UD-1200 vs. Jabe UD-1200 PRO vs. JBC CD-2SQE - need Firmware for UD-1200

[JimKnopf]

Hello,
i use a JBC CD-2SQE for years now which came with a T210 handle. Nice device, but for heavy parts like big heatsinks, transformer or heavy copper multi layer PCB i sometimes wished for more power at the tip. I compared some JBC clones and decided to buy the Jabe UD-1200 but failed at the order process on ali. There were two models, UD-1200 and UD-1200 PRO and i didn't realized that the PRO has a T210 handle. I saw the PRO offer with 3 extra tips and thought PRO must be better than not PRO version. I read about the bad T245 clone handles and bought the original JBC 245 handle and original C245 cardridges from a well known local distributor.

Today the Jabe device arrived and to my surprise, there was a T210 handle. I thought no problem, i already got the T245 handle, just plugin and enjoy.

The Jabe UD-1200 PRO heats up the original T245 handle to around 110 degree even if the device is set to 300 or more.
I compared the PCB from my PRO version with images from UD-1200 or Best BST-933b device. The only difference i could find is this white multioptocoupler that some devices had but which is not assembled on all devices.
I guess the Jabe UD-1200 uses the same hardware as the UD-1200 PRO but software is different. I could not change the power setting in the menu. It is set to 30W.

I read some posts and watched some videos to learn, the original JBC uses pin 1,2,5 on the Hirose connector for T245 and the T210 additionally uses pin 6 (center pin) which is connected to pin 5, both grounded. If pin 6 is connected, the JBC provides 12V to the tip, if only pin 5 is connected, 24V are provided to the tip. I should have read that before buying the Jabe because the T245 handle works well with my JBC CD-2SQE. Using the T245 handle on this device makes it a CD-2BQE modell. Same specs, "E" controller board, same power etc. It seems i bought the Jabe UD-1200 PRO for nothing.

Option A is, selling the Jabe as it's brandnew and unused (no fun factor).

Option B is, turning the UD-1200 PRO into a UD-1200 version (to have some fun).

I guess i need the firmware of a UD-1200 for that. Is there someone able and willing to grab the firmware from his Jabe device and provide it to me for educational purpose?

BTW. The T210 handle from the Jabe UD-1200 PRO version uses another pinout. It doesn't use pin 6. It uses only pin 1,2,5. I guess i can turn the T210 clone on my original JBC into a glow stick because it will use 24V instead of 12V.

Any help getting the T245 tip on the Jabe UD-1200 PRO working is welcome.

[thm_w]

Google finds no information on the "UD-1200 pro" other than a single aliexpress listing with no information as to the differences.
Maybe you can provide some more info or photos. Is there any included manual?

https://www.eevblog.com/forum/reviews/jabe-ud-1200-soldering-station-nice-jbc-clone/

[JimKnopf]

@thm_w Yes there is a manual, i attach it as images. I also took some photos.

[JimKnopf]

The device in comparison to my JBC one.

[JimKnopf]

The board itself

[JimKnopf]

The connectors of the handle:
1. left, T210 Jabe clone
2. middle, T210 JBC original
3. right, T245 JBC original

IMG_20230814_150459.jpg is the connector from inside the Jabe UD-1200 PRO.

[JimKnopf]

I have some readings on the transformer output while connector was plugged into the board.

Handle connector has 7,61 V AC (RMS).
Blue wire of the handle connector is connected straight to pin 3 of the transformer.

Can someone confirm this measurements on a Jabe UD-1200 / Best BST 933b?

[JimKnopf]

From STM32 manual, the STM32F103RB ARM Cortex M (128k/20k flash/ram memory) has a combined JTAG/SWD-DP.
On the chip itself i could see a clock signal / data signals. The 2x10 pin row looks like a default JTAG port. So i tried to find JTAG signals there. No luck with the JTagulator.   

I will try flying wires next. I guess the ATMLH028 (AT24C256C) 256Kbit I2C serial eeprom stores user setup data. I try to dump its data with a programmer.

Interesting pins on the STM32F103RB are:
31 VSS_1 GND
60 Boot_0

USART 1
41 PA 8       USART1_CK
42 PA 9       USART1_TX
43 PA 10     USART1_RX
44 PA 11     USART1_CTS
45 PA 12     USART1_RTS

JTAG
7  NRST       NRST
46 PA 13     JTMS / SWDIO
49 PA 14     JTCK / SWCLK
50 PA 15     JTDI
55 PB 3       JTDO
56 PB 4       JNTRST

[JimKnopf]

I could read the ATML028_AT24C256 eeprom. But it doesn't look like firmware data.

[thm_w]

I asked the seller about the pro and they seemed clueless.
Its possible to extract the firmware on a protected STM32F103. But yeah, without someone with a UD-1200 to compare the eeprom and firmware data too its going to be a bit difficult.

SWD, SWCLK, and NRST is generally all thats used for programming.

[JimKnopf]

...
Its possible to extract the firmware on a protected STM32F103. But yeah, without someone with a UD-1200 to compare the eeprom and firmware data too its going to be a bit difficult.

SWD, SWCLK, and NRST is generally all thats used for programming.

@thm_w I saw your thank you on a related older post about stm32f1 firmware extraction. Maybe you can give me some hints.
I'm diving into that python extraction script. I think i can manage to get a used UD-1200 to do the task.

I'm starting here:
https://blog.zapb.de/stm32f1-exceptional-failure/
https://github.com/doegox/stm32f1-firmware-extractor
https://github.com/dmitrystu/sboot_stm32

[JimKnopf]

@thm_w I added a used Jabe UD-1200 to my soldering station collection.

I grabbed the data from the UD-1200 eeprom and compared it with the data from UD-1200-PRO. It is different.

To dump the STM32F103 firmware i soldered pinheaders to both pcb and used the segger. I also tried my TIAO Tumpa board. But something was not proper set in the config file. I didn't want to spend time on SWD_EN setting in the tumpa.cfg so i used the segger and openodc for both devices.

     openocd -f interface/jlink.cfg -c "transport select swd" -f target/stm32f1x.cfg

I dumped the data using stm32f1-firmware-extractor from https://github.com/doegox/stm32f1-firmware-extractor

     python3 ./main.py 0x00000000 --binary 16384  32768 > Jabe_UD-1200.bin (and of course Jabe_UD-1200-PRO.bin for the other device)

Both files have the same size of 64KB 128KB.

The file command tells me:

# file Jabe*
Jabe_UD-1200.bin:     ARM Cortex-M firmware, initial SP at 0x20002300, reset at 0x080001cc, NMI at 0x080001d4, HardFault at 0x080001d6, SVCall at 0x080001de, PendSV at 0x080001e2
Jabe_UD-1200-PRO.bin: ARM Cortex-M firmware, initial SP at 0x20002308, reset at 0x080001cc, NMI at 0x080001d4, HardFault at 0x080001d6, SVCall at 0x080001de, PendSV at 0x080001e2

Unfortunally, the UD-1200 firmware SD-V3.02.01 is from 2020/01/03 . It's in english which is perfect. But it doesn't support the three temperature presets like the Jabe UD-1200-PRO with firmware version SD-V3.02.03 from 2021/07/26 and my original JBC.

I now have the dump files. But i'm not sure if it's complete. If someone have a newer firmware version for UD-1200 feel free to send me a PM or leave a comment here. Before playing around with programming the STM32F103 i will dump the firmware again using another methode. I got a chipwhisperer husky in my shelf. I will try the gliching trick on the Jabe devices.

Maybe @tv84 can assist me with firmware analysis?

Edit: The STM32F103RB has 128KByte of Flash memory.
 

[JimKnopf]

I read the flash again because the STM32F103RB has 128KB and i compared all files. The 128KB dump files are filled with FF at the end. So no data is missing from memory size i guess.

[DavidAlfa]

And where are the dumps?

[tv84]

Looking at the dumps, at first sight they seem consistent.

BUT...

The PRO dump doesn't contain valid ARM code... The non-PRO contains valid code but both contain bad data every 0x200 bytes.

Look at the attached image. (I loaded the raw dump directly at 0x80000000)

See the FF FF FF FF FF FF FF FF zone? It overwrites good code.

[DavidAlfa]

OOB? Out of band area? It's a STM32, not nand memories.
I loaded them into Ghidra, the code pointed by the reset vector address doesn't make sense.
Lots of garbage everywhere! Maybe the output is corrupted?
Do you have any blue pill where you could write a protected firmware, read it back, then compare?
The non-pro has weird a pattern "07 00 00 20" repeating every 0x100 bytes starting at 0x14, repeating at 0x114, 0x214, 0x314... all along the file.

[tv84]

OOB? Out of band area? It's a STM32, not nand memories.
I loaded them into Ghidra, the code pointed by the reset vector address doesn't make sense.
Lots of garbage everywhere! Maybe the output is corrupted?

I had corrected my post... Yes, the dump seems to have a consistent read error every 0x200 bytes. Maybe it has to do with the reading glitch script?

[DavidAlfa]

No idea! BTW in my case I see bad data every 0x100 bytes, read my previous message.

[tv84]

No idea! BTW in my case I see bad data every 0x100 bytes, read my previous message.

In the PRO dump. The non-PRO seems 0x200.

BTW, my rhetoric question was for Jim.

Edit: You're right, both have an error area every 0x100 bytes. The probability of having this code:

ROM:8000BC14 07 00                             MOVS            R7, R0
ROM:8000BC16 00 20                             MOVS            R0, #0

every 0x100 must be 0.

Interesting to see that it's only a aprox. 0x30 bytes area every 0x100 that is wrong... The other 0xD0 bytes seem OK.

And to make matters worse, the PRO dump starting at 0x2C40 must have all bytes bad... Something happened at that moment. Until then the behavior/problems were the same as in the non-PRO dump.

Do you have any blue pill where you could write a protected firmware, read it back, then compare?

This would be the best action.

[JimKnopf]

@DavidAlfa @tv84 Thank you guys for your effort. I compared the blue pill dev boards. The cheap ones seems to have chinese fake chips. Some reliable ones have a STM32F103C6 or C8 which come with 64KB flashmemory.

See https://www.st.com/en/microcontrollers-microprocessors/stm32f103.html

The Jabe devices using the RB version which has 128KB flashmemory.

I ordered the ST NUCLEO-F103RB dev board, awaiting delivery on friday.

[DavidAlfa]

Try flashing a bluepill with this, use ST-Link utility to set RDP1.
Bin file in Release folder.
The program checksums a big text array, the on-board led (PC13) will blink slowly (1Hz or so) if ok, or very fast if wrong.

Then read it back with the firmare extractor method and check what you got.
Only the first 64KB are used.

[JimKnopf]

@DavidAlfa
@tv84

I now have a blue-pill board and a ST-nucleo here for testing. I flashed the mentioned file 103_test.bin to both devices and read it back.

The blue-pill board was a bit tricky. I couldn't get it to work with the j-link. But a st-link-V2 clone did it (after adding a line to the cfg).

For flashing the file and setting the RDP bit i used the ST Programming software. I read it back two times. One time without RDP and one more time with RDP enabled.

To read it back i used again openocd and stm32f1-firmware-extractor-master.

For the blue-pill:
  openocd -f interface/stlink.cfg -c "transport select hla_swd" -f board/stm32f103c8_blue_pill.cfg
and in the other terminal
  python3 ./main.py 0x00000000 --binary 32768 > bluepill+RDP_read-test.bin

For the ST-nucleo:
  openocd -f interface/jlink.cfg -c "transport select swd" -f target/stm32f1x.cfg
and in the other terminal
  python3 ./main.py 0x00000000 --binary 32768 > ST-nucleo+RDP_read-test.bin


I had a lot of this messages:

sp (/32): 0x20000200

[stm32f1x.cpu] halted due to single-step, current mode: Handler DebugMonitor
xPSR: 0x0100000c pc: 0xfffffffe msp: 0x200001e0
Info : halted: PC: 0xfffffffe
pc (/32): 0xfffffffe

xpsr (/32): 0x0100000c

[stm32f1x.cpu] halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000200 msp: 0x20005000
DEPRECATED! use 'write_memory' not 'array2mem'
DEPRECATED! use 'write_memory' not 'array2mem'
pc (/32): 0x20000002

xpsr (/32): 0x01000000

sp (/32): 0x20000200

[stm32f1x.cpu] halted due to single-step, current mode: Thread
xPSR: 0x01000000 pc: 0x20000004 msp: 0x20000200
Info : halted: PC: 0x20000004
pc (/32): 0x20000004

xpsr (/32): 0x01000000

[stm32f1x.cpu] halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000200 msp: 0x20005000
DEPRECATED! use 'write_memory' not 'array2mem'
DEPRECATED! use 'write_memory' not 'array2mem'
pc (/32): 0x20000002

[DavidAlfa]

And the most important part? Did the original file match with what you read back?

[JimKnopf]

@DavidAlfa Seems the original file doesn't match to the files i read back. And there is also a difference between the blue-pill file with RDP on and RDP off. The St-nuclue files with RDP on/off match. Same md5sum. But they are different to the orig file.

So something is wrong with the extraction tool. I will try my other option, grabbing the flashmemory with the chipwhisperer.

Or do you have a hint how fix the extraction tool?

[JimKnopf]

Even if it doesn't help with the actual problem with the stm32 firmware extractor. But I got the blue-pill to work with the j-link.
I had to add "set _CPUTAPID 0" (instead of 0x1ba01477) in openocd/scripts/target/stm32f1x.cfg to suppress id error.

Another thing i read in openocd manual is, HLA-SWD mode (HLA = High-level adapters) which openocd supports for j-link and ST-link V2 adapter, does not work with the stm32f1-firmware-extractor tool. Because the tool uses the command maskisr that is not supported by HLA-SWD mode. And last but not least, the ST-Nucleo board has an integrated debug port on the upper side that uses HLA. I changed the wiring, only using the lower side of the ST-Nucleo board. Only 4 wires are needed like on the blue-pill.

Pinout for J-Link to ST-Nucleo board
   J-Link            ST-Nucleo CN7
   1 Vdd 3,3V         16 Vdd 3,3V
   4 GND                8   GND (or 19/20/22)
   7 SWDIO            13 PA13 (SWDIO after reset)
   9 SWCLK            15 PA14 (SWCLK after reset)

I was able to flash both devices with the J-Link and set the RDP option byte in openocd.
Now the readout for each device with or without RDP option byte matches but is different between blue-pill and ST-Nucleo and both are different to the original file. This is the actual main cause i'm stucked into. There has been no development in the stm32f1-firmware-extraction tool since the tool was released a few years ago.

https://www.eevblog.com/forum/microcontrollers/dumping-stm32-protected-firmware/

... However the extraction has its issues, every few bytes cannot be read, the ones which match up certain IRQ vectors(7-13) ...

To set option byte in openocd i used this commands (consider that RDP level 1 is option 0 and RDP level 2 is option 1 in openocd, both can be set with lock or unlock):

  openocd -f interface/jlink.cfg -c "transport select swd"  -c "adapter speed 3500" -f target/stm32f1x.cfg
    # in the other terminal
  telnet localhost 4444

    init
    reset halt
    # to read the actual setting
    stm32f1x options_read 0
       device id = 0x20036410
       flash size = 128 KiB
       option byte register = 0x3fffffc
       write protection register = 0xffffffff
       read protection: off
       watchdog: software
       stop mode: no reset generated upon entry
       standby mode: no reset generated upon entry
       user data = 0xffff
    # to activate RDP1
    stm32f1x lock 0
    reset halt

    init
    reset halt
    stm32f1x options_read 0
       option byte register = 0x3fffffe
       write protection register = 0xffffffff       
       read protection: on
       watchdog: software
       stop mode: no reset generated upon entry
       standby mode: no reset generated upon entry
       user data = 0xffff
    # to deactivate RDP1
    stm32f1x unlock 0
    reset halt
    exit

After unlocking RDP1, the flashmemory will be deleted.

To flash it again in openocd i used this commands (while openocd still running).

    telnet localhost 4444

  init
  halt
  flash write_image erase <full path to>/103_test.bin 0x8000000
  verify <full path to>/103_test.bin
  reset run
  exit

The read command (while openocd still running):

time -p python3 ./main.py 0x00000000 --binary 32768 > ST-nucleo+RDP_read-test_new_PA13_PA14.bin
real 2719,66
user 18,80
sys 18,08

md5sum *.bin
f4ee82421a72b1210870185930cfc3f8   103_test.bin
8dbf03eeac65d567487ec8d0b63b4694  bluepill-noRDP_read-test_new3.bin
8dbf03eeac65d567487ec8d0b63b4694  bluepill+RDP_read-test_new.bin
668ce2d0bfb4a4abfd5a4fc92660020b    ST-nucleo-noRDP_read-test_new_PA13_PA14.bin
668ce2d0bfb4a4abfd5a4fc92660020b    ST-nucleo+RDP_read-test_newPA13_PA14.bin

I will end this stm32f1-firmware-extractor chapter here and figure out the jupyter notebook stuff for the chipwhisperer. Maybe a solution  like in this example will do the trick https://prog.world/read-secure-firmware-from-stm32f1xx-flash-using-chipwhisperer/

[DavidAlfa]

If you had to hack the Tap ID, then it's a clone, so it makes no sense to attack it, you want to extract the fw from a genuine stm32.

Maybe a glitch attack?
https://github.com/CTXz/stm32f1-picopwner


Edit: I tried it. Had some baffling issues, which I got around.
When it finally worked, it gave me a perfect firmware dump.

For this to work you'll likely need to modify the board, as the stm32 is powered by a Pico pin, you will need at least to remove all the capacitors and everything connected to VDD, otherwise the glitch will be filtered out or it might consume too much for the pico.
The easiest would be to desolder the stm32 and put it into a breakout board.

[JimKnopf]

I ordered some pico H/WH devices and some breakout boards for 32 to 100 pin chips. The pico devices will arrive next week. Looks like a cheap and reliable solution. No need to use the chipwhisperer (maybe next time).

[DavidAlfa]

I tested it with a J-Link V8 clone from aliexpress, which seem to use a relabeled CKS32F103 (CPUTAPID =  0x2ba01477).
It also worked! But I had to apply the patch, adding set CPUTAPID 0 to target/stm32f1x.cfg.
In my case the openocd folders lived in /usr/share/openocd/scripts.

[JimKnopf]

@DavidAlfa And how did you do that? Can you provide the secrets?

[DavidAlfa]

I mean I extracted the firmware from the Jlink clone using this same attack.

[DavidAlfa]

JimKnopf, regarding your PM, did you follow the fixes I made here? (Posted in an earlier message).
https://github.com/CTXz/stm32f1-picopwner/issues/2

Buepill boards normally have two jumpers for boot0/boot1.
For boot0, remove the jumper and connect the cable in the pin at the middle of the 3.
For Boot1, don't use any resistor, just place the jumper to "1" position.

Just like shown in the github repo (Click for larger pic):

[JimKnopf]

@DavidAlfa

It's wired up correcly. The blue-pill is powered by the pico. I can set/unset RDP and programm the blue-pill with the ST-Link V2 clone.

Each device is recognized, config files are present, openocd works, every thing is fine and should work.

The only thing is, it doesn't work. I didn't remove any component from pico/blue-pill. I added a 10k resistor to the blue-pill boot1/3,3V pin. I guess it's more software related. I also tried external powered USB hub.

I'm running the stm32f1-picopwner on a Arch system which means it's a rolling release.
  openocd-git 0.12.0.r73.g1998b1e5a-1
  python 3.11.5-1
  python-pyserial 3.5-5

I got an error each time i execute the dump.py script:

Please select the USART used by the STM32F1 target to dump firmware
1: USART1 - RX: PA10 TX: PA9)
2: USART2 - RX: PA3  TX: PA2)
3: USART3 - RX: PB11 TX: PB10)
Enter 1, 2 or 3: 1
Press enter to load the target exploit firmware to the SRAM

Traceback (most recent call last):
File "/media/root/Daten/...[...].../stm32f1-picopwner/dump.py", line 479, in <module>
    upload_target_fw(get_target_fw_bin(args.targetfw, sram_entry_point, usart))
File "/media/root/Daten/...[...].../stm32f1-picopwner/dump.py", line 295, in upload_target_fw
    raise Exception(
Exception: Failed to load target firmware to SRAM
openocd output: Error: Invalid command argument

It's the first time i use a RP pico board. I just pressed the button and connected to usb port. It show up as drive. I put the attack.uf2 file on it which leads to a reboot of the pico. Seems it works as expected.

[JimKnopf]

Tried the ST-Nucleo board as target. It gave me this errors:

Waiting for Pi Pico to be connected... (Looking for /dev/ttyACM0)
Device connected to serial port /dev/ttyACM0
Waiting for debug probe to be connected...
Debug probe connected to STM32F1 target
Traceback (most recent call last):
  File "/...[...].../stm32f1-picopwner/dump.py", line 419, in <module>
    rdp_status = get_rdp_status()
                 ^^^^^^^^^^^^^^^^
  File "/...[...].../stm32f1-picopwner/dump.py", line 255, in get_rdp_status
    raise Exception(
Exception: Could not determine read protection status
openocd output: TARGET: stm32f1x.cpu - Not halted

[DavidAlfa]

The problem is clear:

openocd output: Error: Invalid command argument

Something might have changed in newer versions of Openocd.

Try Ubuntu 20, boot a live system and try there.
It seems to me your Linux it's too new. Like always happens.

In your last case, I had the same error.

I repeat, did you modify the dump.py script as I explained?

EDIT: It turns out OpenOCD 0.10 and 0.12 have some differences.
My fix should not be applied for OpenCD 0.12!

You can make some tests. Connect the STlink to the target (BluePill / STM32 Nucleo):

In one window, run:
    openocd -f interfaces/stlink.cfg -f target/stm32f1x.cfg

Should start a debug session. Now open another window:
    telnet localhost 4444

And you should be in the openocd shell.

Try running these commands:
init 
reset halt
stm32f1x options_read 0

Code: [Select]

> init                   
> reset halt             
[stm32f1x.cpu] halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000200 msp: 0x20005000
> stm32f1x options_read 0
option byte register = 0x3fffffe
write protection register = 0xffffffff
read protection: on
watchdog: software
stop mode: no reset generated upon entry
standby mode: no reset generated upon entry
user data = 0xffff


[JimKnopf]

@DavidAlfa
There was no need to change dump.py. I got the stlink.cfg in place. Works great if i start openocd with stlink v2 clone manually. I can flash the blue-pill and read RDP status in openocd:

> stm32f1x options_read 0
device id = 0x20036410
STM32 flash size failed, probe inaccurate - assuming 128k flash
flash size = 128 KiB
option byte register = 0x2a92bfe
write protection register = 0xffffffff
read protection: on

As you can see, the original typing "read protection: on" from dump.py is correct in my case (for my openocd version).

I tried the openocd commands by hand and compared the response message from openocd.

The command from dump.py line 266:

["init", "reset halt", "exit"],

should give the output "pc: 0x20000" used in line 270.
When i do this manually in openocd i get this:

> init
> reset halt
[stm32f1x.cpu] halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000200 msp: 0x20005000
>

Could this cause the error?

[DavidAlfa]

pc: 0x08000200 means it's booting from flash, so BOOT1 is set wrong. Forget the resistor. Just:

- Set BOOT1 jumper to 1.
- Remove BOOT0 jumper, connect to pico GPIO5.
- Press reset button on the Bluepill / Nucleo board.

And try the openOCD test again.

[JimKnopf]

@DavidAlfa

> init
> reset halt
[stm32f1x.cpu] halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x20000108 msp: 0x20005000

Now it matches to dump.py.

[JimKnopf]

Loading the image file works.

> load_image /...[.\ \..].../stm32f1-picopwner/target/target_108_usart1.bin 0x20000108
2104 bytes written at address 0x20000108
downloaded 2104 bytes in 0.140170s (14.659 KiB/s)

Something must be wrong with line

479: upload_target_fw(get_target_fw_bin(args.targetfw, sram_entry_point, usart))

I have a blank in the path name which i had to escape when loading the file manually in openocd.

[JimKnopf]

Oh noooo. The path was causing the error. I moved the whole directory to my home dir and started again. No longer a blank in the path name let me start the process.

Press enter to load the target exploit firmware to the SRAM

Target firmware loaded to the SRAM
Waiting for debug probe to be disconnected...
Warning: Disconnect the debug probe from the target, not just the host USB port!
Debug probe disconnected from STM32F1 target

Attack ready
Press enter to start dumping firmware

 00 50 00 20 01 02 00 08 ef 01 00 08 f1 01 00 08
 f3 01 00 08 f5 01 00 08 f7 01 00 08 00 00 00 00

...
 70 6f 73 75 65 72 65 2c 20 65 6c 69 74 20 6d 61
 67 6e 61 20 6d 6f 6c 6c 69 73 20 64 6f 6c 6f 72
 2c 20 76 65 6c 20 63 6f 6e 76 61 6c 6c 69 73 20
 6c 65 6f 20 6c 65 63 74 75 73 20 61 74 20 6e 69

...
 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

Target has stopped sending data, assuming dump is complete
Dumped 65536 bytes
Output saved to dump.bin

[JimKnopf]

@DavidAlfa

The dump.bin matches your 103_test.bin file until the last few bytes.

[DavidAlfa]

I could replicate the issue, seems to happen sometimes when connecting the STLink VDD to the target board.
But only happened few times. No idea otherwise. Maybe loose wires.
And never connect the debugger unless you're told to do so.

Now, for the nucleo board, there must be a jumper somewhere to isolate VDD, you should open it.

The dump.bin matches your 103_test.bin file until the last few bytes.

It's fine. The original file doesn't use the entire 64KB, so the rest is padded with FF.

[JimKnopf]

@DavidAlfa

Today i tried the trick with the Jabe UD-1200 PRO board. At the moment, i get this error:

Traceback (most recent call last):
  File "/.../stm32f1-picopwner/dump.py", line 419, in <module>
    rdp_status = get_rdp_status()
                 ^^^^^^^^^^^^^^^^
  File ".../stm32f1-picopwner/dump.py", line 255, in get_rdp_status
    raise Exception(
Exception: Could not determine read protection status
openocd output: TARGET: stm32f1x.cpu - Not halted

When connecting the ST-Link V2 clone (Vcc included), i can read the RDP status. To me it looks like the pico can't power the target board. This is one of the mentioned issues on github project page:

The power draw of the target board is too high for the Pi Pico to handle (Try buffering the power pin with a BJT or MOSFET)

I connected external 3,3V to the board Vcc pin1 on the JTAG pin-header and powersupply GND to the pico GND. I swapped the pico-GND connector from UD-122 Pro board to the Emiter pin of a BD139 NPN transistor, pico GP2 (Vcc) pin via 10k resistor to BD139 base pin and it's collector pin to GND on the UD-1200 PRO board. I also connected the ST-Link V2 clone GND to the pico GND.
With this NPN transistor as a switch, i get the same error.

Edit: I added one connection from 3,3V via 1k resistor to pin 28/PB2 that is not visible in the image.

[DavidAlfa]

Are you sure BOOT0 isn't connected directly to gnd? I see that a lot.
But yeah, the problem is probably the capacitance.
Even if you add a transistor, the problem remains, the capacitors will filter out the ultra short power cut.

Better you transfer it to the breakout board.

[JimKnopf]

@DavidAlfa Boot0 was indeed connected to GND. I ordered some breakout boards and placed the STM on it and wired up the connection to the pico and ST-Link probe. I first tried only VDD_1/VSS_1. Then i connected the other VDD_2/VSS_2 to VDD_4/VSS_4 pins to power the STM32F103.

SWDIO is connected to PA13/Pin46 and SWCLK to PA14/Pin49.  Dump.py is waiting for debug probe to be connected. Light on ST-LinkV2 is on, not flashing. Something is missing i guess.

I tried to connect via openocd directly without the pico. But openocd telling

Info : STLINK V2J42S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.213132
Error: init mode failed (unable to connect to the target)

Do i need additional connections on the STM32F103? Never used to run a chip off the board.

[DavidAlfa]

First connect vdd and gnd directly to power. Then try making the stlink talk to it.
It should really work like that.
Make sure you're connecting SWD to the right pins!

[JimKnopf]

@DavidAlfa OK, i added VBAT and VDDA to VDD pins. Still no luck with pico/stm32f1-picopwner.

Waiting for Pi Pico to be connected... (Looking for /dev/ttyACM0)
Device connected to serial port /dev/ttyACM0
Waiting for debug probe to be connected...
Debug probe connected to STM32F1 target
Traceback (most recent call last):
  File "/...[...].../stm32f1-picopwner/dump.py", line 419, in <module>
    rdp_status = get_rdp_status()
                 ^^^^^^^^^^^^^^^^
  File "/...[...]...stm32f1-picopwner/dump.py", line 255, in get_rdp_status
    raise Exception(
Exception: Could not determine read protection status
openocd output:

But, if i connect the STLinkV2 without the pico, i could start openocd and read the readprotection status (NRST and VDD connected to STLinkV2, GND and VDD disconnected from pico).

> init
> reset halt
[stm32f1x.cpu] halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080001cc msp: 0x20002308
> stm32f1x options_read 0
option byte register = 0x3fffffe
write protection register = 0xffffffff
read protection: on
watchdog: software
stop mode: no reset generated upon entry
standby mode: no reset generated upon entry
user data = 0xffff

Small progress, chip seems to work. I was afraid i could have burned the chip during desoldering. I will try another breakout board with 64 pins. This one is for up to 100 pins. I double checked the wires. But maybe the board has an issue.

[DavidAlfa]

The automatic debugger detection might mess things up, it does a closed loop checking for the debugger, waiting for 1 second between, but a check migh run while you're still messing with the wires and fail in the next step.

Try this code at line 411:

Original:

Code: [Select]

# Wait for debug probe to be connected to the STM32F1 target
print("Waiting for debug probe to be connected...")
wait_dbg_probe_connect()
print("Debug probe connected to STM32F1 target")

Modified:

Code: [Select]

# Wait for debug probe to be connected to the STM32F1 target
input("Connect the debugger and press Enter")
wait_dbg_probe_connect()
print("Debug probe connected to STM32F1 target")

So you must press enter to continue after connecting the debugger, the connection will be solid.


Or, adding a delay after the debugger was detected to ensure everything is properly connected already:

Code: [Select]


# Waits until the debug probe is connected
def wait_dbg_probe_connect():
    while not debug_probe_connected():
        time.sleep(1)  # Wait for 1 second before retrying   
    time.sleep(2)  # Wait for 2 second after detected


[JimKnopf]

@DavidAlfa All the dump.py tweaks doesn't help. The problem seems to be in another direction. I swapped the chip to the 64pin breakout-board, wired up all connections. Same story. Then i tried this:

1. Started dump.py
2. Connected pico to USB
3. Removed NRST from pico GPIO4 (yellow wire) and connected it to the STLinkV2 RST
4. Connected the STLinkV2 to USB

and the script started.

When ordered to remove the STLinkV2 from target, i reconnected NRST to the pico first before removing the wires from STLinkV2.

Waiting for Pi Pico to be connected... (Looking for /dev/ttyACM0)
Device connected to serial port /dev/ttyACM0
Waiting for debug probe to be connected...
Debug probe connected to STM32F1 target
STM32F1 target is confirmed to be read protected
Detected SRAM entry point offset: 0x108 (0x20000108)
Please select the USART used by the STM32F1 target to dump firmware
1: USART1 - RX: PA10 TX: PA9)
2: USART2 - RX: PA3  TX: PA2)
3: USART3 - RX: PB11 TX: PB10)
Enter 1, 2 or 3: 1
Press enter to load the target exploit firmware to the SRAM

Target firmware loaded to the SRAM
Waiting for debug probe to be disconnected...
Warning: Disconnect the debug probe from the target, not just the host USB port!
Debug probe disconnected from STM32F1 target

Attack ready
Press enter to start dumping firmware


Timeout: No data received from target
Please consult the README for troubleshooting steps

I compared voltage level on NRST pin, connected to pico vs. STLinkV2.
NRST to STLinkV2 i read 3,26V whereas the pico has 1,17V. A bit too low i guess. But i don't know why. I tried another pico. Same voltage on this pin. Strange behavior.

[DavidAlfa]

Mine sits at 2.7V, consuming 63uA. This is indeed very strange.

Edit: It seems the Pico sets the inputs in pull-down mode by default. So this might explain it. Whe have the STM32 pullup fighting the Pico pulldown.
Quick fix: Add a 1K pullup resistor between nRST and VDD. STM32's VDD, not PICO's! Otherwise it'll affect the voltage glitching.
Proper fix: Correct this in code. But setting up the toolchain, fixing the usual 1834 errors to compile, which indeed happened, so f***m it I'm going to sleep, just use the resistor!

[JimKnopf]

@DavidAlfa I added the two lines to attack.c and rebuild it. No errors during build (Arch linux).

I tried both variants. With the pull-up resistor in place (tried 1k and 10k) it runs the script but fails at dump state with a timeout.

Waiting for Pi Pico to be connected... (Looking for /dev/ttyACM0)
Device connected to serial port /dev/ttyACM0
Connect the debugger and press Enter
Debug probe connected to STM32F1 target
STM32F1 target is confirmed to be read protected
Detected SRAM entry point offset: 0x108 (0x20000108)
Please select the USART used by the STM32F1 target to dump firmware
1: USART1 - RX: PA10 TX: PA9)
2: USART2 - RX: PA3  TX: PA2)
3: USART3 - RX: PB11 TX: PB10)
Enter 1, 2 or 3: 1
Press enter to load the target exploit firmware to the SRAM

Target firmware loaded to the SRAM
Waiting for debug probe to be disconnected...
Warning: Disconnect the debug probe from the target, not just the host USB port!
Debug probe disconnected from STM32F1 target

Attack ready
Press enter to start dumping firmware


Timeout: No data received from target
Please consult the README for troubleshooting steps

Using the fix with the two lines in attack.c, i get the same error. Even if i use both, attack.c fix and pull-up resistor, i get alway the timeout error. Only the voltage level varies. Maybe it's time to replace the chip to the Jabe board to test if it's still alive.

[DavidAlfa]

Well, at least now nRST sits at 3.3V, right?

I tried building in Ubuntu 23, cloning pico sdk, installing gcc-arm-none-eabi.
I had to force the compiler or it wouldn't find it.

Code: [Select]

CC=arm-none-eabi-gcc CXX=arm-none-eabi-g++ make
Now all I get is missing _exit entry error.
As I don't really need this, I refused to go further, I could see the usual Linux can of worms from miles away.
Not another entire afternoon fixing stupid things missed by someone else! 

Are you sure the uart connection is ok and not reversed?

If you have any usb-serial dongle, force boot0=1, connect vdd and check if stm32CubeProg detects the mcu in bootloader mode.
It shouldn't erase anything!

[JimKnopf]

@DavidAlfa Maybe you want to try my attack.uf2 file.

[DavidAlfa]

As expected, CubeProg detects it and shows a readout protection warning.

The new attack fw works perfect, now nRST idles at 3.3V as it should.

Hmm... are you also connecting BOOT1 to VDD through a 1-10K resistor?
BOOT1 is PB2, pin 20 (48-pin package) or pin 28 (64-pin).

[JimKnopf]

@DavidAlfa I tried stm32cubeprogrammer with a UART debugger. It detects the chip and show up the same msg like in your example.

I then connected oscilloscope probes to Boot0, NRST and TX to watch whats going on in the very moment i hit enter to dump the firmware. Colors are Boot0 = yellow, NRST = violett, TX = blue.  It is possible, that TX logic level 0 is not as low as it needs to be to get accurate readings. There is a 0,78 V offset to 0 level.

[DavidAlfa]

There's TX activity so it's definitely working!
You're getting only timeout? Not even a byte read back?
Are your sure TX and RX aren't swapped?
GPIO0 goes to to STM32 pin 58, GPIO1 goes to 59.

Also, did you join all the 5 VDD/VDDA and VSS/VSSA groups?
There's a lot of noise, try adding a 100nF cap to STM32's VDD.

Post a proper picture showing all the connections and setup!

[JimKnopf]

@DavidAlfa Same story with another pico.

[DavidAlfa]

Nah I don't think it's the pico! Must be something with the connections.

[JimKnopf]

@DavidAlfa Wait...what? USART1 pin 58/59? Thats not the default config and it's not in the dump.py instruction.

I only tried this combination :
USART1
pico GPIO0 TX green   to Pin43_PA10 RX stm32     
pico GPIO1 RX orange to Pin42_PA9   TX stm32       

or
USART2
pico GPIO0 TX green   to Pin17_PA3 RX stm32
pico GPIO1 RX orange to Pin16_PA2  TX stm32

or
USART3
pico GPIO0 TX green   to Pin30_PB11 RX stm32
pico GPIO1 RX orange to Pin29_PB10 TX stm32

Pin 58_PB6 / 59_PB7  didn't work.

[DavidAlfa]

Ahh sorry I counted it wrong!
PA9/PA10 pin numbers are 30/31 for 48-pin package, and 42/43 for 64-pin.

I just noticed the picture in the repo is backwards! Should be:

STM32    RX=PA10 (43)    TX=PA9(42)

GPIO0-->PA10    GPIO1-->PA9

[JimKnopf]

@DavidAlfa To me, this image

https://www.eevblog.com/forum/reviews/jabe-ud-1200-vs-jabe-ud-1200-pro-vs-jbc-cd-2sqe-need-firmware-for-ud-1200/?action=dlattach;attach=1879867;image

illustrates the finish of step 3, the end of stage 1 and the start of stage 2 described on github project page:

https://github.com/CTXz/stm32f1-picopwner#step-3-exploit-firmware---stage-1
The chip is recognized, rdp mode is detected, the target board exploit firmware is uploaded, the glitch is done and the chip is booting from flash because boot0 is low. I will paste a high resolution picture of the VDD and GND wires later. Maybe the last point of the troubleshooting list

https://github.com/CTXz/stm32f1-picopwner#troubleshooting

is the problem. The Jabe UD-1200 PRO board is from 2021.
I will wire up a second breakout board and test the chip from older UD-1200 (non PRO) device. 

[DavidAlfa]

But until the very last step, everything is done by the ST-Link, not using the uart pins

[JimKnopf]

@DavidAlfa I got the data 

I don't know why, i put the pico into a breadboard, reconnected wires and...it just worked like expected.

Thank you again for your help and patience.

[DavidAlfa]

Hurray! But... it's very likely that the fw is using more than 64KB, there's data until the very last byte.
The target sram firmware will always read 64KB, it's hardcoded!

So we need to recompile for 128KB, or patch the binaries...

[JimKnopf]

Oh, so i just have to change it to 128? I modified all three 64u parts in main.c and recompiled.

[JimKnopf]

Done.

[DavidAlfa]

Great!   

Edit:
Humm for some reason DBGMCU_ID reads 0 when reading it from the target firmware so flash detection is not working.

Edit2:
However Flash Size Register does work, so I made a new PR. Flash size detection

Tested working!

Also adding a delay in the probe detection makes it work much better.
I would have all kind of errors after connecting the debugger, like unknown RDP status, etc, because "sleep(1)" delay could end *now*, when you're still connecting the wires, making enough contact to detect it, but instantly fail in the next step because you're still moving them.

[JimKnopf]

I tried the 512u change in main.c and was waiting until now. I just watched the filesize. Around 3 MB now, it was still running. I stopped the process.

[DavidAlfa]

Haha, ignore that previous crappy test. See my previous message with the updates.

[JimKnopf]

@DavidAlfa Your changes working great. The only thing is, my wiring sometimes results in timeouts. I will use short dupont wires next time instead of the 30 cm antennas i use at the moment.

Filesize 131072 bytes, FF's at the end. Looks pretty good.

[DavidAlfa]

Radio aficionados must be wondering why they're getting so much noise lately!
Probably not  problem for the 9600baud UART, but might with the SWD.
Next step is to make the target fw compute and send a checksum, also dump.py,  and compare both to ensure data is good.

[JimKnopf]

Oh, yes the content is the same.
I did it this time on another device (Chuwi LarkBox with Ubuntu on it), not on my Arch Notebook.

md5sum *.bin
d0682f71bb13499986941489eb6ea683  Jabe-Pro128k.bin
d0682f71bb13499986941489eb6ea683  Jabe-Pro-auto.bin

[JimKnopf]

I put another breakoutboard together with the second STM32F103RB6 from Jabe UD-1200 non-Pro device.

This time i didn't use dupont wires to the pico but 7cm silicone flex wires, directly soldered to the board and pinheaders.
No more timeouts and lower noise. 100% success rate at dumping.

The only thing is, it does not stop at 131072 bytes. It reads more FF's and blow up the output file with this zeros. I stopped the process and cut the file after 128k.

@DavidAlfa Did you do changes in targets.zip file on github? I just downloaded the file to test on my Arch Notebook.
What can cause the not-stopping reading?

[DavidAlfa]

It reads the size the STM32 reports! Can't read the picture, is it really a RB? Not RC or RE?
Leave it running, it might be a 256 or 512KB part. Worry if you get more than 512KB!
Yeah, the signals look much cleaner now and nope!, I made no more changes since then.

[JimKnopf]

@DavidAlfa

I was probably too impatient. The chinese made RB type STM32F103 MCU seems not matching ST's specs.

[JimKnopf]

Looks like a large block of data is identical in both firmwares at the beginning.

At the end, the Pro has slightly more data. But not that much.

[DavidAlfa]

Doesn't seem fake, perhabs ST sold the same die as RB at certain moment.
Now time to write the non-pro fw into the pro station!
Even having the fw backup, I'd preserve the original stm32s, just in case, getting a new STM32F103RB for testing.
If data after 128K is FF all the way to the end, trimming to 128K will probably work just fine.

[JimKnopf]

I wanted to see if there is anything interesting in the code. I loaded the bin file into ghidra using the svd loader for stm32f103. It seems, if you represent the knowledge for reverse engineering on one single meter, i'm stuck at the second mm. I thought i could find text from menu or something else. Nothing obvious to see to me.


@DavidAlfa I will look in my shelf if i have any spareparts with a STM32F103RB. If not, i will just flash the MCU from Pro device.

No risk, no fun.

[DavidAlfa]

Also did I. I got the main function for both fw, but that was all.
Ghidra didn't recognize some pointers automatically, that's why it doesn't make sense at first.
Symbol Tree->Functions->there you have main.

I'm not really interested in reverse-engineering the entire thing, I don't even own a Jabe!

[JimKnopf]

I resoldered both STM32F103 to their boards. Both devices were working as expected with original firmwares and RDP still on.

I used the JLink to disable RDP and to programm the Jabe UD-1200 PRO first. Quite easy with the 2x10 pinheader.

openocd -f interface/jlink.cfg -c "transport select swd" -f target/stm32f1x.cfg
    (and in another terminal)
telnet localhost 4444
init
reset halt
stm32f1x unlock 0
reset run
init
reset halt
flash write_image erase /...[...].../Jabe-UD1200-128k.bin 0x8000000
reset run
exit

After that, the device turned on and showed only the welcome screen. System doesn't start up. I tried all combinations on the buttons while starting the device, without success.
I then tried to flash quick and dirty the eeprom in the PRO version with data from non-PRO Version using a pomona clamp. Unfortunately, this didn't work.
I had to desolder the eeprom and programm with adapter instead of the easy way using a pomona clamp. 

The PRO then started, and i had english language. But i couldn't use the OK button. The OK button did the same as the down button. I was not able to use the menu. After reflashing both, eeprom and STM32f103 the PRO startet and i was able to use the OK button to use the menu. Picking up the T245 handle i could change temp. To my surprise, the device had the same temp limit on the tip like i had with the original firmware when using a T245 handle. Remember, the PRO came with T210 handle.

So far, no luck with my idea just swapping the firmware and use the PRO with a T245 handle.

The UD1200 non-PRO was my next victim. While the PRO showed me the welcome screen after flashing, the UD-1200 did nothing.
Usually there is a beep when turning on the device. It was just dead. I also desoldered the eeprom like i did on the PRO. I programmed the eeprom with data from PRO eeprom.

After that, the non-PRO device turned on and showed me the welcome screen but failed to start the system. The PRO firmware does not work on the non-PRO device. I reflashed the non-PRO firmware (while the eeprom still had it's data from PRO version) and the device starts as expected. Temperature on display matches the temp on the tip.

The only thing was, the counter had zeros.

Flashing is very easy once the RDP is turned off.
If there is any brave UD-1200 owner with a newer firmware that supports the three temperature presets and is willing to extract the firmware and eeprom content please contact me.

[yangzs]

It's an honor to download your program. It would be even better if you could manually set the firmware length.
Can designing such a circuit board work properly?

[yangzs]

Can you make your project support the GD32F103 chip? Where do I need to modify to read the firmware of GD32F103?

[JimKnopf]

@yangzs Your circuit

https://www.eevblog.com/forum/reviews/jabe-ud-1200-vs-jabe-ud-1200-pro-vs-jbc-cd-2sqe-need-firmware-for-ud-1200/?action=dlattach;attach=1884736

looks perfect. It will work.

A circuit design like in this picture

https://www.eevblog.com/forum/reviews/jabe-ud-1200-vs-jabe-ud-1200-pro-vs-jbc-cd-2sqe-need-firmware-for-ud-1200/?action=dlattach;attach=1875904;image

could be used for 48 and 64 pin together in one board.

[yangzs]

If it can support GD32F103, it would be even more perfect. Can you give me some guidance?

[DavidAlfa]

The PRO firmware does not work on the non-PRO device.

I guess you''ll have to reverse engineer the schematic. Initially it might look similar, but have very different connections in the end.
Perhabs a simple pullup resistor tells it to behave like a pro/non-pro.
Go figure!

[JimKnopf]

@yangzs The GD32F103 is pin compatible. Flashmemory has same start address. Flash memory size is bigger. Just try it. You may open a new thread in Microcontroller section if you need further advice.

[yangzs]

The waveform is like this, and it can only read 2 bytes. What's wrong with this?

[DavidAlfa]

What's going on? Last messages make no sense. Are you guys talking through PM?

[yangzs]

It's already evening now
Only two bytes can be read out
I should do this

[JimKnopf]

@DavidAlfa No PM. He tries to hijack the thread or focus on STM32F103 comparable chips. Has nothing to do with the Jabe topic. I recommended to @yangzs to open a new thread in Microcontroller for further advice.

[DavidAlfa]

Hah! Unbelievable.
yangzs go ask elsewhere where they talk about GD32, or make your own thread! 
Spamming a random STM32 thread asking for this makes no sense at all.

[yangzs]

@JimKnopf I mentioned it's also TM32F103RE，sleep_ms(15); Change to 30 Everything Okay。

[DavidAlfa]

Ah,ok, so it was related, attacking a GD32 . My apologies.
Yeah GD32 load the firmware from the external flash so it takes longer to boot.

[balu.2019@gmail.com]

Hi Jim,

I was struckup in the below step after transferring IC (STM32F103C8) to the breakout board.

Info : STLINK V2J42S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.213132
Error: init mode failed (unable to connect to the target)

i tried the connectios as per attahced, but still no luck.

Could you please help me on the connections

Regards,
Balakrishna

[JimKnopf]

Have a look at my post https://www.eevblog.com/forum/reviews/jabe-ud-1200-vs-jabe-ud-1200-pro-vs-jbc-cd-2sqe-need-firmware-for-ud-1200/?action=dlattach;attach=1881895

In the top right corner you can see the connection to the ST-Link adapter. Be aware you have to connect the all GND pins together and also connect all Vcc pins to 3,3V as shown in my picture.

[balu.2019@gmail.com]

Hi Jim,

Thanks for the info, I have connected as per you suggestion (connected all GND pins together and also connected all Vcc pins to 3,3V)

howerver I am getting Timeout : No data recieved from Target.

Could you please help on this.

Regards,
Balakrishna

[JimKnopf]

Did you notice the two pull-up resistors? If i remember correctly, the value was 10k.

[balu.2019@gmail.com]

Hi Jim,
Yes, I have used 1K resistors, but still same error Timeout : No data recieved from Target..

for Vcc pins I am using the STLink v2 power (3.3v) , but getting only 2.7v to the IC pins, will it be the issue?

Regards,
Balakrishna

[JimKnopf]

Scroll through the messages on page 2. I had same error until i used a pullob resistor on nrst https://www.eevblog.com/forum/reviews/jabe-ud-1200-vs-jabe-ud-1200-pro-vs-jbc-cd-2sqe-need-firmware-for-ud-1200/msg5047624/#msg5047624

[alexgubanow]

hello everyone, i do have jabe ud-1200 for already few years, bought from banggood with English firmware.
Recently it has switched to Chinese on it is own and i have no idea how to switch it back...
Any ideas? What are the chances of language setting being stored in eeprom?

[JimKnopf]

@alexgubanow

I'm pretty sure the settings are stored in Eeprom. Can you share a dump of your eeprom?

What firmwareversion does your UD-1200 has? Can you post the service manual? Is there an option for language settings?

[balu.2019@gmail.com]

Hi,

I am able to get the bin file for F103, can i use same for STM32F2 series as well

Thanks & Regards,
Bala

[JimKnopf]

@balu.2019@gmail.com Please respect the forum rules and create a new topic in microcontroller section.

[JimKnopf]

After a while, i reviewed the PCB's and just found the different between the two PCB'S, the UD-1200 and the UD-1200 Pro. It's resistor R41, 2,2 kOhm (222 top marking).

R41 is present at the UD-1200 PCB. The pads are unpopulated on the UD-1200 Pro PCB.

After placing a 2,2 kOhm resistor to the Pro PCB, flashing the UD-1200 firmware, it starts as a UD-1200 with full temperature on T-245 handle. The T-210 handle is not recognized when R41 is soldered.

[DavidAlfa]

So it's possible after all?

[JimKnopf]

@DavidAlfa Sorry for my late response. I managed to burn Q12 somehow. It's a PNP transistor (2F marking). I was waiting for the part. Q12 switches negativ voltage to the two LM358. Has something to do with detecting a tool plugged in and temperature adjustment for the tip. After replacing Q12 i could make an image.

To answer the question, yes, it works. Both devices are now fully working UD-1200 with T245 handles at full heat.

Now i just need a newer firmware. I'm in contact with someone willing to grab the firmware from his newer UD-1200.