search

area-8051 / stcgal-patched

stcgal patched to support STC8G, STC8H, STC8A8K64D4 and STC32G.
16 stars 4 forks source link

STC8G1K08 frequency trimming unsuccessful above ~27 MHz #3

Closed weiszpal closed 1 year ago

weiszpal commented 1 year ago

According to its datasheet, microcontrollers part of the STC8G family have an integrated high-precision internal IRC oscillator, which can be used in two frequency ranges depending on the content of the IRCBAND register:

The adjustment range of the 20M band is about 14.7MHz to 26MHz (LSB=0). The adjustment range of the 33M band is about 24.5MHz to 42.2MHz (LSB=1).

However, I cannot use the upper frequency band via frequency trimming using the -t 30000 parameters. I read in the FAQ that the safe range is 5MHz-30MHz. Can this range be extended somehow?

area-8051 commented 1 year ago

Thank you for reporting. The programming protocol is described in the Chinese version of the data sheet, I'll have a close look at it to see if/where there's a bug in the implementation.

area-8051 commented 1 year ago

So, I've experimented a bit and my STC8G1K08 exhibits a strange behaviour.

Here is the first packet exchange using an STC8H8K64U, which accepts calibration on the whole specified range:

Target frequency: -> Packet data: 46 B9 6A 00 18 00 08 00 00 FF 00 00 10 FF 10 00 20 FF 20 00 30 FF 30 05 46 16 <- Packet data: 46 B9 68 00 18 00 08 00 26 00 47 00 41 00 74 00 AD 01 31 00 F5 01 D9 04 58 16

The segment in bold face defines 4 calibration intervals (2 x 16-bit big-endian word each). As you can see, these intervals overlap slightly to cover the whole 0x26-0x1d9 range.

Now, here's what I get with my STC8G1K08:

Target frequency: -> Packet data: 46 B9 6A 00 18 00 08 00 00 FF 00 00 10 FF 10 00 20 FF 20 00 30 FF 30 05 46 16 <- Packet data: 46 B9 68 00 18 00 08 00 86 00 EC 00 86 00 EC 00 86 00 E9 00 83 00 E9 06 47 16

Here, we have more or less 4 times the same interval instead of 4 overlapping ones, making it impossible to calibrate the MCU outside of this single interval.

I can reproduce this problem with an STC8G1K08-TSSOP20 version C and an STC8G1K17-DIP16 version D (the latest mentioned in the documentation).

At this point, I wonder whether this could be a silicon bug...

Working under Linux, I can't check if the same behaviour shows up when using STC-ISP (Windows-only). If you use Windows, you may want to try it and report back here. The latest version is: http://www.stcmcudata.com/STCISP/stc-isp-15xx-v6.91L.zip

area-8051 commented 1 year ago

I managed to run STC-ISP with Wine and could calibrate an STC8G1K08A at 34MHz. Next step is to sniff the communication to see how STC-ISP does it. :)

mightymos commented 1 year ago

I managed to run STC-ISP with Wine and could calibrate an STC8G1K08A at 34MHz. Next step is to sniff the communication to see how STC-ISP does it. :)

I have Windows and a Saleae logic analyzer clone along with a STC15W408AS board if you need help.

area-8051 commented 1 year ago

Thank you! :) However it will work on STC15, as well as on STC8H4, STC8H8, STC8A8K64D4. This issue only affects some STC8G1 and STC8H1.

area-8051 commented 1 year ago

I couldn't fully reverse engineer the protocol used by the STC8G series, so I used a hack to solve the issue and let me take my time to further dig into the protocol.