padding breaks STC15F204EA

[zerog2k]

just updated to latest master and it seems there is a new option which pads writes out.. My code usage is almost the full space of 4k, so when I write, this is now attempting to pad out to 4096 bytes (whereas before it was something like 3840 bytes). This is failing. I noticed for whatever reason on this chip, I am actually unable to write the entire 4096 bytes, but strangely writing anything over 4089 up to 4096 bytes will cause a write error with "Protocol error: verification checksum mismatch"

I wonder if this started with commit 6c0af885514f3bcc26512e108622392a5e5eff6e

latest master output:

stcgal/stcgal.py -p /dev/tty.SLAB_USBtoUART -P stc15a -t 11059 -l 9600 -b 9600 main.hex
Waiting for MCU, please cycle power: done
Target model:
  Name: STC15F204EA
  Magic: F394
  Code flash: 4.0 KB
  EEPROM flash: 1.0 KB
Target frequency: 11.076 MHz
Target BSL version: 6.7R
Target options:
  reset_pin_enabled=True
  watchdog_por_enabled=True
  watchdog_stop_idle=True
  watchdog_prescale=256
  low_voltage_reset=True
  low_voltage_threshold=2
  eeprom_lvd_inhibit=True
  eeprom_erase_enabled=True
  bsl_pindetect_enabled=False
Loading flash: 3798 bytes (Intel HEX)
Trimming frequency: 11.059 MHz
Switching to 9600 baud: done
Erasing 16 blocks: done
Writing 4096 bytes: ...............................................................Protocol error: verification checksum mismatch
Disconnected!

2738118e8f1488fff5904d560a6d2f3099e0c679 is the last commit i could rollback to and verify that it is working (other commit after that give a usb error). The output is:

stc_diyclock jens$ make flash
stcgal/stcgal.py -p /dev/tty.SLAB_USBtoUART -P stc15a -t 11059 -l 9600 -b 9600 main.hex
Waiting for MCU, please cycle power: done
Target model:
  Name: STC15F204EA
  Magic: F394
  Code flash: 4.0 KB
  EEPROM flash: 1.0 KB
Target frequency: 11.072 MHz
Target BSL version: 6.7R
Target options:
  reset_pin_enabled=True
  watchdog_por_enabled=True
  watchdog_stop_idle=True
  watchdog_prescale=256
  low_voltage_reset=True
  low_voltage_threshold=2
  eeprom_lvd_inhibit=True
  eeprom_erase_enabled=True
  bsl_pindetect_enabled=False
Loading flash: 3798 bytes (Intel HEX)
Trimming frequency: 11.076 MHz
Switching to 9600 baud: done
Erasing 16 blocks: done
Writing 3840 bytes: ............................................................ done
Finishing write: done
Setting options: done
Target UID: F39401A0056485
Disconnected!

[grigorig]

You can use git bisect to find out which commit caused the regression. It would also be helpful to have a detailed output with packet data (-D). To get rid of the USB error, just install pyusb for Python 3.

Edit: just a hunch: IIRC the BSL stores the UID in the last bytes of Flash or something like that, which may cause the verification failure. I changed stcgal to align Flash writes to 512 byte boundaries (this is similar to STC-ISP) for compatibility. Earlier writes didn't hit the last block in your case, but now they do. So yes, maybe try reverting https://github.com/grigorig/stcgal/commit/6c0af885514f3bcc26512e108622392a5e5eff6e.

[grigorig]

Unfortunately I cannot reproduce this problem with an otherwise very similar STC15F104E, BSL version 6.7Q.

[zerog2k]

Ok, here is the working debug output: https://gist.github.com/zerog2k/b23a2a034f4b2ee92bb90e8b342a2354

here's the non-working debug output: https://gist.github.com/zerog2k/f0651b44d1d16e57813404fb46127370

here is the file I'm trying to upload: https://gist.github.com/zerog2k/2bd918532f6ac434e7097457fd7fdf40

I confirmed after installing pyusb that rolling back to commit 366a3a5 is working. I do suspect you are on to something here, as I seem to also recall in playing around with IAP and direct memory pointers that the UID was at the end of code space.

[grigorig]

Maybe it's actually safe to just drop the verification. Serial transfers use parity. On top of that, each packet is checked against a 16 bit modular sum. The additional verification seems overkill. It might have made sense on the earlier protocol iterations which didn't use parity and only an 8-bit modular sum. The later protocol iterations actually dropped the verification part, which makes me think it's considered safe to do by STC. I've also never seen an actual verification mismatch.

Please try the branch https://github.com/grigorig/stcgal/tree/no_verification which drops the verification.

[zerog2k]

Thanks. no_verification branch seems to flash just fine for me.

[Drummerboy458]

LwwdeMacBook-Air:Desktop lww$ stcgal -a -P stc89 -p /dev/tty.wchusbserial1410 -b 9600 -l 9600 -D main.ihx Cycling power: done Waiting for MCU: <- Packet data: 00 <- Packet data: 46 B9 68 00 29 50 FD 00 00 00 00 00 00 00 00 00 00 00 00 5F 00 00 72 43 00 F0 51 05 80 00 FF FF FF FF 38 20 18 09 06 60 09 93 16 <- Packet data: 00 <- Packet data: 00 <- Packet data: 46 B9 68 00 29 50 FD 00 00 00 00 00 00 00 00 00 00 00 00 5F 00 00 72 43 00 F0 51 05 80 00 FF FF FF FF 38 20 18 09 06 60 09 93 16 <- Packet data: 30 <- Packet data: 2E <- Packet data: 30 <- Packet data: 30 <- Packet data: 30 <- Packet data: 30 <- Packet data: 30 <- Packet data: 30 <- Packet data: 56 <- Packet data: 20 <- Packet data: 20 <- Packet data: 4E <- Packet data: 61 <- Packet data: 4E <- Packet data: 63 <- Packet data: 6D <- Packet data: 0D <- Packet data: 0A <- Packet data: 30 <- Packet data: 2E <- Packet data: 30 <- Packet data: 30 <- Packet data: 30 <- Packet data: 30 <- Packet data: 30 <- Packet data: 30 <- Packet data: 56 <- Packet data: 20 <- Packet data: 20 <- Packet data: 4E <- Packet data: 61 <- Packet data: 4E <- Packet data: 63 <- Packet data: 6D <- Packet data: 0D <- Packet data: 0A <- Packet data: 30 <- Packet data: 2E <- Packet data: 30 <- Packet data: 30 <- Packet data: 30 <- Packet data: 30 <- Packet data: 30 <- Packet data: 30 <- Packet data: 56 <- Packet data: 20 <- Packet data: 20 <- Packet data: 4E <- Packet data: 61 <- Packet data: 4E <- Packet data: 63 <- Packet data: 6D <- Packet data: 0D <- Packet data: 0A <- Packet data: 30 <- Packet data: 2E <- Packet data: 30 <- Packet data: 30 <- Packet data: 30 <- Packet data: 30 <- Packet data: 30 It just cannot stop.Can someone help me?