trouble with stc15f204ea

[zerog2k]

Opening an issue here to document, as I would much prefer to using native python solution for programming as opposed to the stc-isp in wine.

stcgal seems like it is programming but the program never seems to start up, and no serial console output seen. I'm using sdcc 3.5.0. The exact same program is programmed and working OK with latest stc-isp (6.85I) in wine.

stcgal output:

jens@spire:~/Dropbox/stc/stcgal$ ./stcgal.py -p /dev/ttyUSB1 -P stc15 ../blinky/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.062 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=0
  eeprom_lvd_inhibit=True
  eeprom_erase_enabled=False
  bsl_pindetect_enabled=False
Trimming frequency: 11.076 MHz
Switching to 19200 baud: done
Erasing 14 blocks: done
Writing 3584 bytes: ........................................................ done
Finishing write: done
Setting options: done
Target UID: F39401BB006617
Disconnected!
jens@spire:~/Dropbox/stc/stcgal$ 

stc-isp output:

Checking target MCU ... 
fixme:comm:set_queue_size insize 8192 outsize 8192 unimplemented stub
  MCU type: STC15F204EA
  F/W version: 6.7R

Current H/W Option:
  . Do not detect the level of P3.2 and P3.3 next download
  . Power-on reset, use the general power-on delay
  . RESET pin behaves as reset pin
  . Reset while detect a Low-Voltage
  . Thresh voltage level of the built-in LVD : 3.14 V
  . Inhibit EEPROM operation under Low-Voltage
  . Hardware enable Watch-Dog-Timer when power-on reset
  . Watch-Dog-Timer pre-scalar : 256
  . Watch-Dog-Timer stop count in idle mode
  . Program can modify the Watch-Dog-Timer scalar
  . Do not erase user EEPROM area at next download

  . MCU type: STC15F204EA
  F/W version: 6.7R

Adjusting frequency ...         [1.213"]
Adjusted frequency: 11.054MHz (-0.051)

Re-handshaking ... Successful           [0.435"]
Current Baudrate: 19200
Erasing MCU flash ...  OK !     [0.704"]
MCU ID : F39401BB006617
Programming user code ... OK !      [1.594"]
Programming OPTIONS ... OK !        [0.079"]

H/W Option upgrade to:
  . Do not detect the level of P3.2 and P3.3 next download
  . Power-on reset, use the general power-on delay
  . RESET pin behaves as reset pin
  . Reset while detect a Low-Voltage
  . Thresh voltage level of the built-in LVD : 3.14 V
  . Inhibit EEPROM operation under Low-Voltage
  . Hardware enable Watch-Dog-Timer when power-on reset
  . Watch-Dog-Timer pre-scalar : 256
  . Watch-Dog-Timer stop count in idle mode
  . Program can modify the Watch-Dog-Timer scalar
  . Do not erase user EEPROM area at next download

  . MCU ID : F39401BB006617
  . MCU type: STC15F204EA
  F/W version: 6.7R

  . Set frequency: 11.059MHz
  . Adjusted frequency: 11.054MHz
  . Trim error: -0.051

  Complete !

[zerog2k]

the blinky example I'm using for ref: https://gist.github.com/zerog2k/f10777fc538f3b6789db

[zerog2k]

from the other issue, found ref to stc15f programming routine in c in what looks like making one mcu program anouther, with some google translate: https://gist.github.com/zerog2k/0a8182562d071fe0cc9f

[grigorig]

Hi,

I don't think I ever tested this MCU. I'm not sure I have one of these. Unfortunately, there is no single protocol for a series, STC seems to change or modify protocols on a whim...

If I get around to redoing my reverse engineering setup, I'll see what I can do to get this chip and the other new ones working.

If you get it working, please submit a PR!

[grigorig]

Oh, just a wild guess: the STC15F104 I used to RE the protocol only has 128 bytes of RAM. That is why the BSL uses smaller block size (64 bytes) for programming. Other STC MCUs with more RAM all seem to use 128 byte blocks. Maybe try to adjust this:

https://github.com/grigorig/stcgal/blob/master/stcgal.py#L1965

[zerog2k]

Thanks for the response, and suggestion. I tried that and it actually hung after erase and start of user program download.

After poking around in the code, I noticed that you dont ever try to do any intel hex unpacking/conversion routine and just use the raw binary bytes, and then it occurred to me to try using raw binary image (sdcc spits out ihex by default which is also supported by stc-isp program). I was able to simply convert ihex to bin with: objcopy -I ihex -O binary main.hex main.bin and now it works! Yay.

Looking back at the stcgal readme, I didn't see any specific mention of this, so perhaps you can make a small note in the readme about using binary vs ihex image (and how to easily convert). If I get some time, I might work on a pr to support ihex input format as an option.

Thanks Grigori!

[zerog2k]

alternatively, included with sdcc is makebin: makebin -p main.hex main.bin which seems to work also for me.

[grigorig]

OK, thanks for the suggestion, I added a note now.

[grigorig]

FYI, there's HEX support now.