Possible compatibility issues with CH340 UARTs

[merbanan]

Hi, I bought a cheap rfid copier.

http://www.ebay.com/itm/Handheld-Portable-125Khz-RFID-Duplicator-Copier-Writer-for-EM4100-T5577-Card-/191630611446?hash=item2c9e1313f6:g:D7UAAOSwyQtVo4pM

Inside it was a STC89LE52RC mcu driving the whole thing. I soldered the serial port pins on it and ran:

stcgal -P stc89

The output was this: Waiting for MCU, please cycle power: done Target model: Name: STC89C52RC/LE52R Magic: F002 Code flash: 8.0 KB EEPROM flash: 6.0 KB Target frequency: 2.746 MHz Target BSL version: 4.3C Target options: cpu_6t_enabled=False bsl_pindetect_enabled=False eeprom_erase_enabled=False clock_gain=high ale_enabled=True xram_enabled=True watchdog_por_enabled=False Disconnected!

Which sound really promising. With the exception of the wrongly calculated frequency. I clearly see that the crystal is a 22.1184 MHz one. I have another board with a 11.0592 MHz crystal and that returns an output of 11.029 MHz (which is I guess close enough).

While this is a cosmetic issue in the output, will this be an issue when programming the device?

I don't want to try because I don't want to risk bricking the device. If you want your own device to test with I am happy to buy this device for you.

[grigorig]

In the worst case, baud rate calculation and handshake will fail due to incorrectly detected frequency and you can't program the chip. You cannot really brick it, though. Please try to program, in the worst case it won't work. :)

Anyway, I have the exact same chip, so let me try to reproduce this.

[grigorig]

I can't seem to reproduce this. An STC89C52RC (5V variant, though) with a 16, 20 or 24 MHz crystal works just fine, for instance. Clock is correctly detected and programming works. 22.1184 MHz I don't have right here. It doesn't matter whether the 6T mode is enabled or not either, both work. 6T affects timing, so it needs special consideration, but stcgal handles that fine.

Can you please provide output with the -D option (which will dump received and sent packets)? Either just status or a complete failed or successful program cycle. You may also want to play around with handshake baud rate (-l option).

Here's an example of a programming cycle with a 24 MHz crystal:

Waiting for MCU, please cycle power: <- Packet data: 46 B9 68 00 3B 00 2D 7A 2D 7A 2D 7A 2D 7A 2D 7A 2D 7A 2D 76 2D 7A 43 43 FD F0 02 82 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CE 16
done
Target model:
  Name: STC89C52RC/LE52R
  Magic: F002
  Code flash: 8.0 KB
  EEPROM flash: 6.0 KB
Target frequency: 23.948 MHz
Target BSL version: 4.3C
Target options:
  cpu_6t_enabled=False
  bsl_pindetect_enabled=False
  eeprom_erase_enabled=False
  clock_gain=high
  ale_enabled=True
  xram_enabled=True
  watchdog_por_enabled=False
Loading flash: 110 bytes (Binary)
Switching to 19200 baud: checking -> Packet data: 46 B9 6A 00 0C 8F FF D9 00 4E A0 80 4B 16
<- Packet data: 46 B9 68 00 0C 8F FF D9 00 4E A0 80 49 16
setting -> Packet data: 46 B9 6A 00 0B 8E FF D9 00 4E A0 C9 16
<- Packet data: 46 B9 68 00 0B 8E FF D9 00 4E A0 C7 16
testing -> Packet data: 46 B9 6A 00 0C 80 00 00 36 01 F0 02 1F 16
<- Packet data: 46 B9 68 00 06 80 EE 16
-> Packet data: 46 B9 6A 00 0C 80 00 00 36 01 F0 02 1F 16
<- Packet data: 46 B9 68 00 06 80 EE 16
-> Packet data: 46 B9 6A 00 0C 80 00 00 36 01 F0 02 1F 16
<- Packet data: 46 B9 68 00 06 80 EE 16
-> Packet data: 46 B9 6A 00 0C 80 00 00 36 01 F0 02 1F 16
<- Packet data: 46 B9 68 00 06 80 EE 16
done
Erasing 2 blocks: -> Packet data: 46 B9 6A 00 0D 84 02 33 33 33 33 33 33 2F 16
<- Packet data: 46 B9 68 00 06 80 EE 16
done
Writing 256 bytes: -> Packet data: 46 B9 6A 00 8C 00 00 00 00 00 00 80 01 04 01 36 75 81 07 12 00 6A E5 82 60 03 02 00 02 E4 78 FF F6 D8 FD 01 02 AF 82 8F 06 1F EE 60 0F 7D 90 7E 01 1D BD FF 01 1E ED 4E 70 F7 80 EB 22 AF 82 DF FE 22 E5 B0 F4 F5 B0 75 82 05 11 31 75 82 D0 11 19 E5 B0 F4 F5 B0 75 82 64 11 19 E5 B0 F4 F5 B0 75 82 64 11 19 E5 B0 F4 F5 B0 75 82 64 11 19 E5 B0 F4 F5 B0 80 D6 75 82 00 22 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5A 16
<- Packet data: 46 B9 68 00 07 80 E4 D3 16
.-> Packet data: 46 B9 6A 00 8C 00 00 00 00 80 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F6 16
<- Packet data: 46 B9 68 00 07 80 00 EF 16
. done
Setting options: -> Packet data: 46 B9 6A 00 0A 8D FD FF FF FF FB 16
<- Packet data: 46 B9 68 00 0A 8D FD FF FF FF F9 16
done
-> Packet data: 46 B9 6A 00 06 82 F2 16
Disconnected!

[grigorig]

Just another hunch that came to my mind: if the baud rate is incorrect, the frequency is incorrectly detected. What kind of serial adapter do you use? The detected frequency is exactly 1/8 of the actual frequency, so maybe you were running at 9600 baud instead of 1200 baud for some odd reason. This would cause such a problem.

[merbanan]

The first try I did actually reported a frequency of 22.065 MHz. I forgot to enable debug at that time. But this is the debug output of a bad frequency try.

stcgal -D -P stc89 Waiting for MCU, please cycle power: <- Packet data: 46 B9 68 00 3B 00 05 3A 05 36 05 36 05 36 05 36 05 36 05 36 05 36 43 43 FD F0 02 82 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 76 16 done Target model: Name: STC89C52RC/LE52R Magic: F002 Code flash: 8.0 KB EEPROM flash: 6.0 KB Target frequency: 2.745 MHz Target BSL version: 4.3C Target options: cpu_6t_enabled=False bsl_pindetect_enabled=False eeprom_erase_enabled=False clock_gain=high ale_enabled=True xram_enabled=True watchdog_por_enabled=False -> Packet data: 46 B9 6A 00 06 82 F2 16 Disconnected!

[merbanan]

I don't really want to program this device yet as I don't have the actual firmware that is on the device. Is it possible to extract that somehow ?

[merbanan]

Got a working trace now with -l 2400:

stcgal -D -P stc89 -l 2400 Waiting for MCU, please cycle power: <- Packet data: 46 B9 68 00 3B 00 14 F2 14 EE 14 F2 14 F2 14 F2 14 EE 14 EE 14 EE 43 43 FD F0 02 82 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 BA 16 done Target model: Name: STC89C52RC/LE52R Magic: F002 Code flash: 8.0 KB EEPROM flash: 6.0 KB Target frequency: 22.053 MHz Target BSL version: 4.3C Target options: cpu_6t_enabled=False bsl_pindetect_enabled=False eeprom_erase_enabled=False clock_gain=high ale_enabled=True xram_enabled=True watchdog_por_enabled=False -> Packet data: 46 B9 6A 00 06 82 F2 16 Disconnected!

[merbanan]

The next try reported 5.491 MHz.

[merbanan]

Ok, -l 9600 gives a reliable reading around 22MHz (21.970, 21.962, 21.954, 21.962)

[grigorig]

I don't really want to program this device yet as I don't have the actual firmware that is on the device. Is it possible to extract that somehow ?

Nope... that is an anti-feature of the STC MCUs. It is simply not possible to read back code. Unless there is a backdoor that I do not know about. (...yet)

Your measurements are interesting. What kind of UART do you use on the PC side? I.e. USB adapter or native 16550? Which chip/brand?

[merbanan]

ch341, do you want med to test something else ?

[merbanan]

Regarding reading back code, if you are able to dump the BSL it might be possible to find some way of doing that. I am guessing the BSL is the 2kb part that is missing from 8kb of the eeprom. Fiddling with with eeprom addressing might make it possible to get access to that part of the code.

But I'm just waving my hands now.

[grigorig]

Yes, the BSL is in the upper part of the Flash. I'm not sure if it is possible to read it back. Maybe that is an interesting thing to try next.

Maybe you could try another UART (PL2303 and CP2102 work fine for me) to verify whether your CH340/CH341 is problematic or if it is something different.

[merbanan]

CP2102 (no access to PL2303 currently):

stcgal -D -P stc89 Waiting for MCU, please cycle power: <- Packet data: 46 B9 68 00 3B 00 29 F6 29 F6 29 F2 29 F2 29 FA 29 F2 29 F2 29 F2 43 43 FD F0 02 82 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 82 16 done Target model: Name: STC89C52RC/LE52R Magic: F002 Code flash: 8.0 KB EEPROM flash: 6.0 KB Target frequency: 22.094 MHz Target BSL version: 4.3C Target options: cpu_6t_enabled=False bsl_pindetect_enabled=False eeprom_erase_enabled=False clock_gain=high ale_enabled=True xram_enabled=True watchdog_por_enabled=False -> Packet data: 46 B9 6A 00 06 82 F2 16 Disconnected!

stcgal -D -P stc89 Waiting for MCU, please cycle power: <- Packet data: 46 B9 68 00 3B 00 29 F2 2A 02 2A 02 29 F6 29 FA 29 F2 29 EE 29 FA 43 43 FD F0 02 82 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 A4 16 done Target model: Name: STC89C52RC/LE52R Magic: F002 Code flash: 8.0 KB EEPROM flash: 6.0 KB Target frequency: 22.102 MHz Target BSL version: 4.3C Target options: cpu_6t_enabled=False bsl_pindetect_enabled=False eeprom_erase_enabled=False clock_gain=high ale_enabled=True xram_enabled=True watchdog_por_enabled=False -> Packet data: 46 B9 6A 00 06 82 F2 16 Disconnected!

stcgal -D -P stc89 Waiting for MCU, please cycle power: <- Packet data: 46 B9 68 00 3B 00 29 F6 29 FA 29 F6 29 F6 29 FA 29 FE 29 F6 29 FA 43 43 FD F0 02 82 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 A6 16 done Target model: Name: STC89C52RC/LE52R Magic: F002 Code flash: 8.0 KB EEPROM flash: 6.0 KB Target frequency: 22.103 MHz Target BSL version: 4.3C Target options: cpu_6t_enabled=False bsl_pindetect_enabled=False eeprom_erase_enabled=False clock_gain=high ale_enabled=True xram_enabled=True watchdog_por_enabled=False -> Packet data: 46 B9 6A 00 06 82 F2 16 Disconnected!

stcgal -D -P stc89 Waiting for MCU, please cycle power: <- Packet data: 46 B9 68 00 3B 00 29 FA 2A 02 2A 02 29 F6 29 FA 2A 02 29 FE 29 FA 43 43 FD F0 02 82 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 16 done Target model: Name: STC89C52RC/LE52R Magic: F002 Code flash: 8.0 KB EEPROM flash: 6.0 KB Target frequency: 22.112 MHz Target BSL version: 4.3C Target options: cpu_6t_enabled=False bsl_pindetect_enabled=False eeprom_erase_enabled=False clock_gain=high ale_enabled=True xram_enabled=True watchdog_por_enabled=False -> Packet data: 46 B9 6A 00 06 82 F2 16 Disconnected!

stcgal -D -P stc89 Waiting for MCU, please cycle power: <- Packet data: 46 B9 68 00 3B 00 29 FE 29 F2 29 FE 29 FE 29 FA 29 F6 29 FA 29 FA 43 43 FD F0 02 82 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 B2 16 done Target model: Name: STC89C52RC/LE52R Magic: F002 Code flash: 8.0 KB EEPROM flash: 6.0 KB Target frequency: 22.106 MHz Target BSL version: 4.3C Target options: cpu_6t_enabled=False bsl_pindetect_enabled=False eeprom_erase_enabled=False clock_gain=high ale_enabled=True xram_enabled=True watchdog_por_enabled=False -> Packet data: 46 B9 6A 00 06 82 F2 16 Disconnected!

[merbanan]

So maybe this warrants a note in the documentation about testing different handshake speeds and trying different usb-serial adapters.

[merbanan]

I think the issue can be closed now also. Thanks for the support, I'll be happy top perform any other test you might need.

[grigorig]

I'll leave this open for now, I need to check compatibility with CH340 myself and with other UARTs as well.

However, thanks for the testing, great to see that it works for you now. :)

[grigorig]

I just found this: https://github.com/themadinventor/esptool/commit/1a9b16f63a8338c067b663e42bcbe2af98c68ba5

Please try commit af153a89e7410453670c468195b92a7c34e8a35b, it might fix this.

[merbanan]

Tested 8 times without the baud workaround. 100% success.

[grigorig]

I'm a bit confused. Did you test the patch against your CH340 UART? And now it worked even without the patch? Or is that a typo?

[merbanan]

I checkout out your fix, after that if worked 100%

[merbanan]

Omg I can't spell. I tested one more time before the fix. It failed. Then I tested code with your fix and it worked 100% after that.

[grigorig]

@merbanan I finally got one of these cheap CH341 UARTs. And it doesn't work! :( Apparently the Linux driver doesn't support parity, which is required for all newer STC chips. Which OS / kernel did you use?

[merbanan]

Ubuntu 15.04 with stock kernel.

[merbanan]

And you are correct about parity. There might be patches available for that on the USB mailinglist.

[grigorig]

Well, you were lucky because the old STC89 series don't use any parity. :)

[Wesley-Chan]

For anyone who hits a wall here, all you need to do is to add parity support to the CH341 Linux driver. Here's a patch you can use. https://github.com/karlp/ch341-linux/blob/master/0001-usb-serial-ch341-Add-parity-support.patch

[grigorig]

You don't need to use any patches. Linux as of 4.10 includes parity support in the driver.