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/