STC8A64D4-LQFP44

[digimatt22]

Hello, I am using a PCB that contains the STC8A64D4-LQFP44 device. The board contains a FTDI device (FT234XD-R). When plugged in the FTDI chip is powered from the USB but this rail is not shared to the PCB. I am able to program the board using a windows machine and the STC-ISP software by pressing the download button and then powering on the main part of the PCB. When I try to program using STCGAL (and make files from UNI-STC project) it sits at Waiting for MCU endlessly. Is there any suggestions you can provide on debugging this? I know the STCGAL installation works as I can program a demo board with the STC8A64D4-LQFP48 on it.

Thanks in advance.

[area-8051]

The default value STCGAL_OPTIONS is -a, which means automatic power cycling. Could you try putting STCGAL_OPTIONS := (nothing after =) e.g. after the PROJECT_NAME line? This will disable the automatic mode and allow you to manually power cycle the MCU.

[digimatt22]

I attempted the above but still ended with the same result, except the message please cycle power as appended after Waiting for MCU.

stcgal -p /dev/cu.usbserial-DK0GQ2DT -t 24000 build/c3-firmware.hex Waiting for MCU, please cycle power:

[digimatt22]

If it helps, I have used a logic analyzer to monitor the RX/TX lines of the STC chip during this process. I see a long stream of 7F and then two instances of a response. The response is quite long:

46 B9 68 00 38 50 01 6E 3F 60 4E 20 01 FF FF BF AF FF 00 CE 7F FE 74 55 00 F7 F4 02 86 DD 2E 50 20 24 1F 1D 01 00 00 FE 04 A9 22 08 26 70 11 0A 82 B8 F4 4D 67 7E B0 15 49 16

Is this protocol documented somewhere? I assume this is part of the handshake with STC chip that put it into boot loader mode vs user application mode.

[area-8051]

Can you set STCGAL_OPTIONS := -D and post the output here? It will be more nicely formatted.

[digimatt22]

That was easier than my logic analyzer :-)

stcgal -D -p /dev/cu.usbserial-DK0GQ2DT -t 24000 build/c3-firmware.hex Waiting for MCU, please cycle power: <- Packet data: C0 <- Packet data: 46 B9 68 00 38 50 01 6F C5 03 C4 1A B2 C0 FD FD AF FF 00 D1 F7 FE 74 AB 02 74 F4 02 86 DD 5D 82 02 46 E9 AC 28 18 40 80 FE 04 A9 44 42 66 19 B7 84 05 82 71 D1 4D 67 7E B0 15 <- Packet data: 0E <- Packet data: 16

[area-8051]

Ok, the data stream is corrupt. The culprit is likely pyserial, which STCGAL uses to communicate with the MCU.

You could try STCGAL_OPTIONS := -l 115200 to set the handshake bad rate to 115200 instead of 2400.

The best solution would be to use POSIX system calls instead of pyserial, but this wouldn't work on Windows.

[digimatt22]

I don't need it to work with windows. I only referenced windows above due to testing with the original STC-ISP. I am using OSX on a MacBook Pro M1 (ARM).

[digimatt22]

stcgal -D -l 115200 -p /dev/cu.usbserial-DK0GQ2DT -t 24000 build/c3-firmware.hex Waiting for MCU, please cycle power: <- Packet data: 00 <- Packet data: 46 B9 68 00 38 50 01 6F 62 00 4C 20 01 FF FF BF AF FF 00 D2 DD FE 74 55 01 BA F4 02 86 DD 5D 82 02 46 F4 AC 28 18 40 80 FE 04 A9 22 08 26 70 11 14 12 85 45 4D 67 7E 60 15 0E <- Packet data: 16

That is the output when using -l 115200.

[area-8051]

Please send me an email at: vincent -dot- defert -at- posteo -dot- net I'll reply with a modified protocols.py attached you could try (with STCGAL_OPTIONS := -D).

[digimatt22]

Results Using the modified protocols.py and removing -l 115200

stcgal -D -p /dev/cu.usbserial-DK0GQ2DT -t 24000 build/c3-firmware.hex Waiting for MCU, please cycle power: <- Packet data: 46 B9 68 00 38 50 05 7B 12 03 88 1A 64 C0 FF FF FD AF FD 9D 54 74 FE 74 55 02 E8 F4 02 86 DD B9 82 09 19 A2 AC 28 30 40 00 FE 04 A9 49 42 66 19 B7 84 0A 82 E1 D1 4D 9D F3 82 <- Packet data: 47 <- Packet data: 28 <- Packet data: CA <- Packet data: F1

[area-8051]

So I'll have to reproduce it to find the cause of the bug. Which board has the issue? Do you have a purchase link?

[digimatt22]

I'll try to find a purchase link for the specific PCB but in the past I could only find, this one. I have that board and it programs properly. I will be traveling for the next few days but when I return I will continue to debug some on my side to understand the difference.