Closed Earture closed 8 years ago
The CH340 drivers tend to be buggy, probably on OSX too. So maybe just try another UART. It's strange to see errors at this point, though. Are you sure the MCU isn't defective? Do you have good power supply?
when i used STC-ISP in windows,it works well,and i try to use BusHound to check protocol with same setting(27000 kHz internal,19200)
the picture of STC-ISP detail windows http://www.earture.org/bug.png
the stcgal output:
Sakura:stcgal-1.2 Earture$ python3 ./stcgal.py -p /dev/tty.wchusbserial1410 -P stc15 -D -o clock_source=internal -t 27000 test.hex Waiting for MCU, please cycle power: <- Packet data: 46 B9 68 00 34 50 87 68 8C B0 F7 BB 9F 00 A8 E5 80 FD 26 C6 00 00 72 53 00 F4 08 04 06 70 B0 02 1C 22 25 26 27 00 F4 F0 04 CE FF 90 BF FF FF 15 07 10 60 14 89 16 done Target model: Name: STC15F2K60S2 Magic: F408 Code flash: 60.0 KB EEPROM flash: 1.0 KB Target frequency: 11.069 MHz Target BSL version: 7.2.4S Target wakeup frequency: 34.664 KHz Target options: reset_pin_enabled=False clock_source=internal clock_gain=high watchdog_por_enabled=False watchdog_stop_idle=True watchdog_prescale=256 low_voltage_reset=True low_voltage_threshold=3 eeprom_lvd_inhibit=True eeprom_erase_enabled=False bsl_pindetect_enabled=False por_reset_delay=long rstout_por_state=high uart2_passthrough=False uart2_pin_mode=normal cpu_core_voltage=unknown Loading flash: 167 bytes (Intel HEX) Option clock_source=internal Trimming frequency: -> Packet data: 46 B9 6A 00 20 00 0C 00 C0 80 C0 FF C0 00 80 80 80 FF 80 00 40 80 40 FF 40 00 00 80 00 C0 00 0A D3 16 <- Packet data: 46 B9 68 00 20 00 0C 0C 4A 11 95 17 12 18 57 22 BB 2D 4C 31 7F 45 CF 59 E8 4E 80 6D 57 7C 39 08 CA 16 -> Packet data: 46 B9 6A 00 20 00 0C EF 40 F0 40 F1 40 F2 40 F3 40 F4 40 8B 40 8C 40 8D 40 8E 40 8F 40 90 40 0C 90 16 <- Packet data: 46 B9 68 00 20 00 0C 57 77 57 68 57 90 57 C7 57 EF 58 12 47 A0 47 C3 47 EB 48 27 48 4F 48 45 0A 8C 16 27.013 MHz Switching to 19200 baud: -> Packet data: 46 B9 6A 00 0E 01 8D 40 FE DF FE 4F 81 04 F1 16 <- Packet data: 46 B9 68 00 07 01 00 70 16 -> Packet data: 46 B9 6A 00 0B 05 00 00 5A A5 01 79 16 <- Packet data: 46 B9 68 00 07 05 00 74 16 done Erasing flash: -> Packet data: 46 B9 6A 00 0B 03 00 00 5A A5 01 77 16 Serial port error: read timeout
Does the referenced branch fix your issue?
it still didn't work at all, i'm wrong,dual isn't the reason of error.but i find it maybe sent 0x7f for synchronization with MCU again before Erasing flash(or after handshake),Isn't it strange? CH340 drivers bug on OS X is the answer finally?
oh!!!!!! it works !!!!!!!! it is a delay problem!!! thanks a lot! just add "time.sleep(0.2)" !
`
def handshake(self):
# external clock needs special handling
if self.external_clock:
self.switch_baud_ext()
else:
self.calibrate()
# test/prepare
packet = bytes([0x05])
if self.bsl_version >= 0x72:
packet += bytes([0x00, 0x00, 0x5a, 0xa5])
time.sleep(0.2)
self.write_packet(packet)
response = self.read_packet()
if response[0] == 0x0f:
raise StcProtocolException("MCU is locked")
if response[0] != 0x05:
raise StcProtocolException("incorrect magic in handshake packet")
print("done")
`
output: Sakura:stcgal Earture$ python3 ./stcgal.py -p /dev/tty.wchusbserial1410 -P stc15 -D -o clock_source=internal -t 27000 -b 9600 test.hex Waiting for MCU, please cycle power: <- Packet data: 46 B9 68 00 34 50 87 68 8C B0 F7 B9 9F 01 9B C4 80 FD 26 C1 00 00 72 53 00 F4 08 04 06 70 B0 02 1C 22 25 26 27 00 F4 F0 04 CE FF F2 7F FF FF 15 07 10 60 14 77 16 done Target model: Name: STC15F2K60S2 Magic: F408 Code flash: 60.0 KB EEPROM flash: 1.0 KB Target frequency: 26.986 MHz Target BSL version: 7.2.4S Target wakeup frequency: 34.664 KHz Target options: reset_pin_enabled=False clock_source=internal clock_gain=high watchdog_por_enabled=False watchdog_stop_idle=True watchdog_prescale=256 low_voltage_reset=True low_voltage_threshold=1 eeprom_lvd_inhibit=True eeprom_erase_enabled=False bsl_pindetect_enabled=False por_reset_delay=long rstout_por_state=high uart2_passthrough=False uart2_pin_mode=normal cpu_core_voltage=unknown Loading flash: 167 bytes (Intel HEX) Option clock_source=internal Trimming frequency: -> Packet data: 46 B9 6A 00 20 00 0C 00 C0 80 C0 FF C0 00 80 80 80 FF 80 00 40 80 40 FF 40 00 00 80 00 C0 00 0A D3 16 <- Packet data: 46 B9 68 00 20 00 0C 0C 4A 11 95 17 12 18 57 22 B6 2D 4C 31 7F 45 CA 59 E8 4E 7B 6D 5C 7C 2F 08 B6 16 -> Packet data: 46 B9 6A 00 20 00 0C EF 40 F0 40 F1 40 F2 40 F3 40 F4 40 8B 40 8C 40 8D 40 8E 40 8F 40 90 40 0C 90 16 <- Packet data: 46 B9 68 00 20 00 0C 57 72 57 63 57 90 57 C7 57 EF 58 12 47 9B 47 C3 47 EB 48 27 48 4A 48 40 0A 73 16 27.013 MHz Switching to 9600 baud: -> Packet data: 46 B9 6A 00 0E 01 8D 40 FD BF F3 40 81 04 B6 16 <- Packet data: 46 B9 68 00 07 01 00 70 16 -> Packet data: 46 B9 6A 00 0B 05 00 00 5A A5 01 79 16 <- Packet data: 46 B9 68 00 07 05 00 74 16 done Erasing flash: -> Packet data: 46 B9 6A 00 0B 03 00 00 5A A5 01 77 16 <- Packet data: 46 B9 68 00 0E 03 F4 08 00 98 03 08 19 02 31 16 done Writing 512 bytes: -> Packet data: 46 B9 6A 00 4B 22 00 00 5A A5 02 00 06 02 00 91 75 81 07 12 00 A3 E5 82 60 03 02 00 03 79 00 E9 44 00 60 1B 7A 00 90 00 A7 78 01 75 A0 00 E4 93 F2 A3 08 B8 00 02 05 A0 D9 F4 DA F2 75 A0 FF E4 78 FF F6 D8 FD 78 00 E8 44 00 1C 3C 16 <- Packet data: 46 B9 68 00 08 02 54 00 C6 16 .-> Packet data: 46 B9 6A 00 4B 02 00 40 5A A5 60 0A 79 01 75 A0 00 E4 F3 09 D8 FC 78 00 E8 44 00 60 0C 79 00 90 00 01 E4 F0 A3 D8 FC D9 FA 02 00 03 AE 82 AF 83 7C 00 7D 00 7A 00 7B 00 8A 00 8B 01 C3 E8 9E E9 9F 50 07 0A BA 00 F1 0B 80 EE 1D 9C 16 <- Packet data: 46 B9 68 00 08 02 54 00 C6 16 .-> Packet data: 46 B9 6A 00 4B 02 00 80 5A A5 0C BC 00 01 0D C3 EC 94 88 ED 64 80 94 93 40 DA 22 C2 B5 90 00 32 12 00 62 D2 B5 90 00 32 12 00 62 80 EE 75 82 00 22 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 2A E3 16 <- Packet data: 46 B9 68 00 08 02 54 00 C6 16 .-> Packet data: 46 B9 6A 00 4B 02 00 C0 5A A5 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 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 42 36 16 <- Packet data: 46 B9 68 00 08 02 54 00 C6 16 .-> Packet data: 46 B9 6A 00 4B 02 01 00 5A A5 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 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 41 77 16 <- Packet data: 46 B9 68 00 08 02 54 00 C6 16 .-> Packet data: 46 B9 6A 00 4B 02 01 40 5A A5 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 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 41 B7 16 <- Packet data: 46 B9 68 00 08 02 54 00 C6 16 .-> Packet data: 46 B9 6A 00 4B 02 01 80 5A A5 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 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 41 F7 16 <- Packet data: 46 B9 68 00 08 02 54 00 C6 16 .-> Packet data: 46 B9 6A 00 4B 02 01 C0 5A A5 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 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 42 37 16 <- Packet data: 46 B9 68 00 08 02 54 00 C6 16 . done Finishing write: -> Packet data: 46 B9 6A 00 0B 07 00 00 5A A5 01 7B 16 <- Packet data: 46 B9 68 00 08 07 54 00 CB 16 done Setting options: -> Packet data: 46 B9 6A 00 4B 04 00 00 5A A5 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 01 FF 9C FF 30 FF 50 FF FD 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 F3 7F F7 B9 9F 3D 5D 16 <- Packet data: 46 B9 68 00 08 04 54 00 C8 16 done Target UID: F4080098030819 -> Packet data: 46 B9 6A 00 07 82 00 F3 16 Disconnected!
Huh, that is really odd. I cannot explain why a delay would be required here. Can you confirm that this works reliably and that it also works with other baudrates specified with -b
?
yes, using different baud rates ,it also works well! , but i can't ensure that can work on other platform or chip with the design of PCB、 platform and BSL version are different
just test on OS X 10.11.5
To clarify, does it work without the time.sleep call you added with different baudrates? If not, how much delay do you need to make this work reliably? Is it enough to delay for a very short time, e.g. 5 ms?
sorry,i ignore a point in my PCB,it called “automatic reboot”,when i remove automatic reboot,it works well without time.sleep so the automatic reboot is the reason of the bug
automatic reboot http://www.earture.org/bug1.png
#include"8051.h"
void delay()
{
unsigned char i,j,k;
for(i=4;i>0;i++)
for(j=100;j>0;j--)
for(k=100;k>0;k--);
}
void main()
{
while(1)
{
P35=1;
P34=0;
P33=1;
if(P35==0) //enable or unable
if(P33==0) //CH340 RTS
{
P34=1;
delay();
P34=0;
while(~P33);
}
}
OK, great. I do not fully understand how your automatic reboot works, but I guess I can close this then. On the upside, the investigations around your report actually contributed to making stcgal behave more closely to STC-ISP, so it's all good. :)
usb to serial chip is CH340T
Sakura:stcgal-1.2 Earture$ python3 ./stcgal.py -p /dev/cu.wchusbserial1420 -P stc15 test.ihx Waiting for MCU, please cycle power: done Target model: Name: STC15F2K60S2 Magic: F408 Code flash: 60.0 KB EEPROM flash: 1.0 KB Target frequency: 11.059 MHz Target BSL version: 7.2.4S Target wakeup frequency: 34.664 KHz Target options: reset_pin_enabled=False clock_source=internal clock_gain=high watchdog_por_enabled=False watchdog_stop_idle=True watchdog_prescale=256 low_voltage_reset=True low_voltage_threshold=3 eeprom_lvd_inhibit=True eeprom_erase_enabled=False bsl_pindetect_enabled=False por_reset_delay=long rstout_por_state=high uart2_passthrough=False uart2_pin_mode=normal cpu_core_voltage=unknown Loading flash: 167 bytes (Intel HEX) Trimming frequency: 11.059 MHz Switching to 19200 baud: done Erasing flash: Serial port error: read timeout