It looks like it wasn't correct. The last value sent is probably
supposed to be the trim value for the chosen trim frequency.
Found while investigating grigorig/stcgal#16.
It's not needed on STC12 and up. All transfers are error checked with
parity and a 16-bit modular sum already. STC15 dropped the verification
checksum on the protocol level, it's not sent with the write status
packet, which is a testament to this not being needed.
Some parts store the UID in the last bytes of flash memory and this
verification actually caused incorrect verification failures because
of the verification, which apparently read the UID on verification
readback.
Fixesgrigorig/stcgal#15.
Don't ignore permission denied when looking for a suitable USB device.
Otherwise users don't notice what the problem is, stcgal will just
keep waiting on the prompt.
Completely revamp option handling. This fixes a wrong index of MCS4,
which is now renamed to MCS3. Now programming should be exactly
similar to STC-ISP 6.85M.
This also renames the values of the low_voltage_reset option for
clarity.
Also update the documentation and clarity the meaning of the option
according to protocol family.
Addresses grigorig/stcgal#14.
If a previous stcgal invocation is aborted, we can be in a bad state
upon connect. Add a simple sanity check based on packet length to
detect this and drop unsuitable packets.
The STC15W4 series have an additional USB BSL mode which kind of wraps
the serial protocol. It just uses basic USB control transfers. This
adds support for this mode, based on the existing STC15 code. pyusb is
required as an additional dependency. The new protocol mode is called
"usb15". There are some shortcomings, for instance timing of erase
and programming operations is problematic and right now only delays
are used. Also, only a single USB-ISP device is supported and the
first one found is always used.
Flash programming and setting options has been mildly tested on an
STC15W4K56S4 MCU.
It is possible to lock devices with a password against flashing. This
feature is not currently supported by stcgal, so at least output a
sensible message.
The model of the target MCU and its protocol is detected using model ID provided in the first packet (status packet) from the MCU.
Tested working models include,
IAP15F2K61S2 (BSL version: 7.1.4S, protocol: stc15)
STC15F104W (BSL version: 7.1.4Q, protocol: stc15)
TC11F02E (BSL version: 6.5K, protocol: stc12)
STC10F04XE (BSL version: 6.5J, protocol: stc12)
STC12C5A16S2 (BSL version: 6.2I, protocol: stc12)
STC12C5608AD (BSL version: 6.0G, protocol: stc12)
STC12C2052 (BSL version: 5.8D, protocol: stc12a)
STC90C52RC (BSL version: 4.3C, protocol: stc89)
STC89C52RC (BSL version: 4.3C, protocol: stc89)
STC89C54RD+ (BSL version: 4.3C, protocol: stc89)
STC15F104E (BSL version: 6.7Q, protocol: stc15a)
STC15F104E uses a different status packet protocol than other MCUs; it waits for an ACK packet before sending out the status packet. Another problem is that STC15F104E shares the same model magic with STC15F104W. Fortunately, these two models can be differentiated by their BSL version numbers.
This is inspired by Arduino. Directly before connect, DTR is asserted
for 0.5 seconds and then deasserted again. With a small external
circuit, the MCU can be power-cycled with this control signal.
In case the MCU draws very little power, it may even be possible to
supply power directly from the DTR pin.
The cpu core voltage setting is only available on newer parts, so do not
try to support it on older ones. The option packet is too short on some
parts, which resulted in an assertion hit.
There may be a nicer solution, but this works for now.
Fixesgrigorig/stcgal#6.
Initialization is messed up on older Linux kernels and that results
in 9600 baud being used unconditionally in some cases. Setting the
baud rate separately seems to work around this successfully.
Fixesgrigorig/stcgal#5.
