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

[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.