Recurrent problems flashing STC15F204EA... baudrate / protocols.py confusion...!

[mosagepa]

Hello.
Experiencing here tons of problems trying to flash STC15F204EAs... (I've got 3 of them, no one works)
Description:

• Tried STCGAL with -l 2400 -b 2400 (most if not all other -l and -b combos don' do it, it just stalls)
• I've got to the point where the chip is detected and all things great except when it comes to the switch sample rates point. See -D output (along with some print() checkpoints I've made on my way):
• What I don't come to understand properly I think, is the meaning of that "program-speed = 24MHz or so", all that "230400 // self.baud_transfer).... Given that logs show that my chip is yielding say an initial freq. of 4.696 MHz, later on it negotiates to some 4.917 MHz freq, (see log below), which is quite in the ballpark (so I really don't think trimming is the culprit), what SHOULD then be the parameters or right byte sequence in the Switching baudrates steps, namely:

Switching to 2400 baud: Now calling get_iap_delay with program_speed = 22118400
-> Packet data: 46 B9 6A 00 12 8E 56 9D 0C A1 64 DC 00 83 20 FF 00 05 8C 16

which is the point in which things go bezerk!!! (as you can see I put a loop to gather incoming bytes even if they don't comply with the expected protocol... in an effort to diagnose it somehow...)

And please please can the author explain in layman terms to me, the relationship between the values given to the -l, -b, -t options, the initial "freq", the negotiated "freq" afterwards and the dreaded 24118400, 230400 // ...etc constants, the Python code is mostly auto-explicative but I guess better didactics would help INMENSELY in this effort...

Especially since F104W's are all around and nicely working from the outset, whereas for some strange reason there are lots of frustrated users of F204EA's out there speaking profanities about their STGAL company for nights to come... (I myself been obsessed with trying to diagnose this for an entire WEEK now, come figure...!!)
(so I've done my homework, I'm not just pestering Grigorig, as I say I've diagnosed up to the point I can and understand.... notice that at first these module/s didn't even go PAST the trimming step!!! .... that's all my modifications that got'em up to the SWITCH BAUDRATES point... but to no further avail.... :/sad:/

I'm not in any remote way criticizing Grigorig's efforts, which are only to be praised and acknowledged (there goes a 46 B9 6A 00 80 big ACK to you, man!!! You're the man, but please help me....

I am truly willing to go the extra mile, not just asking for kind help only to retire from this later. I see this precise model F204EA is not truly documented as itself... so I think a great outcome of my problem would be to come up together with a proper script / mod that allows the STC15F204EA model to benefit from STCGAL.

-D output follows. Have peace and thank you in advance!

stcgal -p /dev/ttyS4 -P stc15a -l 2400 -b 2400    -D  STC15L204EA_NRF24L01/NRF_24L01_BASE.hex 
Hi, I'm right here...
self.trim_frequency = 0
Waiting for MCU, please cycle power: <- Packet data: 46 B9 68 00 07 80 00 EF 16
-> Packet data: 46 B9 6A 00 07 80 00 F1 16
<- Packet data: 46 B9 68 00 40 50 04 5E 04 5F 04 5E 04 5E 04 A4 04 A4 00 00 00 00 67 52 FF F3 94 8C EF 3B F5 58 80 FF FF FF FF FF FF FF FF FF FF FF 00 00 00 00 FF FF FF 11 FF FF FF FF 58 50 18 AA 22 FF 54 1F 71 16
done
i=0 --> read 045E; freq_counter acumulado = 1118
i=1 --> read 045F; freq_counter acumulado = 2237
i=2 --> read 045E; freq_counter acumulado = 3355
i=3 --> read 045E; freq_counter acumulado = 4473
i=4 --> read 04A4; freq_counter acumulado = 5661
i=5 --> read 04A4; freq_counter acumulado = 6849
and self.baud_handshake = 2400
Calculated self.mcu_clock_hz = 4696457
Target model:
  Name: STC15F204EA
  Magic: F394
  Code flash: 4.0 KB
  EEPROM flash: 1.0 KB
Target frequency: 4.696 MHz
Target BSL version: 6.7R
Target options:
  reset_pin_enabled=False
  watchdog_por_enabled=False
  watchdog_stop_idle=True
  watchdog_prescale=64
  low_voltage_reset=False
  low_voltage_threshold=3
  eeprom_lvd_inhibit=False
  eeprom_erase_enabled=False
  bsl_pindetect_enabled=False
Loading flash: 1169 bytes (Intel HEX)
Trimming frequency: -> Packet data: 46 B9 6A 00 0D 50 00 00 36 01 F3 94 02 85 16
<- Packet data: 46 B9 68 00 07 8F 00 FE 16
frequency = 4696457
-> Packet data: 46 B9 6A 00 2A 65 58 50 18 AA 22 FF 54 FF FF 06 06 18 00 02 00 18 80 02 00 18 80 02 00 18 FF 02 00 58 00 02 00 58 80 02 00 09 7D 16
<- Packet data: 46 B9 68 00 2A 65 58 50 18 AA 22 FF 54 FF FF 06 06 18 00 04 AB 18 80 06 B8 18 80 06 B8 18 FF 08 C2 58 00 08 C6 58 80 04 5E 0D 94 16
Checkout: len(response) = 36
Checkout: response[0] = 65
Unpacked trim_a, count_a = 5800 08C6
Unpacked trim_b, count_b = 5880 045E
-> Packet data: 46 B9 6A 00 3E 65 58 50 18 AA 22 FF 54 FF FF 06 0B 18 00 02 00 18 01 02 00 18 02 02 00 18 03 02 00 18 04 02 00 18 05 02 00 18 06 02 00 18 07 02 00 18 08 02 00 18 09 02 00 18 0A 02 00 07 50 16
<- Packet data: 46 B9 68 00 3E 65 58 50 18 AA 22 FF 54 FF FF 06 0B 18 00 04 AB 18 01 04 B1 18 02 04 B7 18 03 04 BD 18 04 04 BF 18 05 04 C4 18 06 04 CB 18 07 04 D0 18 08 04 CF 18 09 04 D4 18 0A 04 DB 0F D0 16
Received trim as 1800, count as 04AB
Received trim as 1801, count as 04B1
Received trim as 1802, count as 04B7
Received trim as 1803, count as 04BD
Received trim as 1804, count as 04BF
Received trim as 1805, count as 04C4
Received trim as 1806, count as 04CB
Received trim as 1807, count as 04D0
Received trim as 1808, count as 04CF
Received trim as 1809, count as 04D4
Received trim as 180A, count as 04DB
So best trim = 1800, best count = 04AB
4.917 MHz
Switching to 2400 baud: Now calling get_iap_delay with program_speed = 22118400
-> Packet data: 46 B9 6A 00 12 8E 56 9D 0C A1 64 DC 00 83 20 FF 00 05 8C 16
Now waiting...
Got a 0091... Doesn't work
Got a 0016... Doesn't work
Got a 006B... Doesn't work
Got a 0069... Doesn't work
Got a 009B... Doesn't work
Got a 00A4... Doesn't work
Got a 001A... Doesn't work
Got a 0063... Doesn't work
Got a 003D... Doesn't work

[mosagepa]

Please note that this was done with a "proper" MAX232 interface, not an USB-TTL (those behave even worse!), and indeed the very same MAX232 interface I've used successfully to program both a STC15F104W and several STC89C516 & 52s...

[mosagepa]

UPDATE:
The problem I had with STC15F204EA modules was: these modules were originally conceived to use NRF24L01's wireless modules alongside STC15L204, notice the 'L' which denotes low voltage supply (3V3).
You'll notice you're in the wrong supply range because of the following:

• STC15F204s behave erratically and don't progress on to actual Flash erase & write (neither with STCGAL nor "official" STC-ISP versions)
• You can be easily misled since even if they don't flash, they can actually trim frequency in the range 1.5 up to 6 or 7 MHz, but variably on every execution and requiring 6 initial inquiries in the INFO phase instead of the usual 3 inquiries for this series (see inside STGAL script for details.)

To correctly flash and operate, these STC15F204s must be fed with at least 3V8, and the modules in question, found abundantly on typical Chinese online stores, sport AMS1117 3.3 regulators.

As you can see in mine, there is provision for 0ohm resistors to bridge between either the 5V or (AMS1117 derived) 3V3 to feed the uC:

Originally the 0hms were soldered to the right (3V3 route, on 'R2' mark), I de-soldered the 0ohm resistor and moved it to the left side (as 'R3') where they allow to feed STC15F204EA's with proper 5V.

Now with this mod the modules flash and work flawlessly. :)

As a sidenote, it's really stange that these STC15F204EAs are supposed to come in 28-pin packages, not 20 (at least if we follow their datasheet). The datasheet has interesting remark about "samples", so I don't think my modules sport fake STCs, but that maybe they (STC factory) initially planned on samples with 28-pin but then actual production was done with 20-pin packaging... who knows!

In fact, in the datasheet for F204EAs:
STC15F204EA-en.pdf
in Section "1.3.3 STC15S204EA series Pin Definition" it says:
"STC15S204EA series is the special version of STC15F204EA series MCU, but it has no sample provided currently."

So it seems that these "STC15S204EA" (a 20-pin SOIC variant of the "normal" 28-pin F204EAs) got out of the factory with the labeling F204EA in their silks anyway.

Note that in these modules datasheet (that I link right here), the IC is annotated as "STC15L204", i.e. the 3V3 version, and some of the pins imply SPI-related functions (SCK, MISO, MOSI, ...):

STC15L204_NRF24L01.pdf

But I don't think the 20-pin F204EAs actually soldered on these NRF24L01 prototyping modules really have a SPI implemented in hardware... I've tried to find any info on internal SPI module for these 20 and 28 pin variants, but to no avail, so I guess they just don't provide hardware ISP...

By "ISP" I mean "your everyday SPI hardware" for, as you may know, STC is known by its "innovative" flashing and bootstrapping procedures, which in some cases means a real advantage in terms e.g. of not having to deal with XTALs and caps but the chips running quite fast regardless (BTW, another nice advantage is STC's provision for convenient 11.0592MHz right from the internal clock, which helps to accomodate the usual UART baud rates with a minimal probability that sync fails). On the other hand, more powerful series such as the STC15F2K60S2 do claim (and have) proper SPI in hardware, thanks in part to their higher pin counts in their PDIP 40 and PLCC 44 packagings.

Alas, in the schematic above, if you change STCL204 by STCF204 (STCS204, strictly speaking) then the pins that appear labelled as P5.4 and P5.5 in silkscreen & schematics should get re-annotated as P0.0 and P0.1, respectively, see Section 1.3.3 in the STCF204EA datasheet.

So between the datasheet's confusion and this somewhat dodgy supplier's substitution of the implied STC15L204s by 5V but reduced-pin count (20 vs 28) versions of the STCF204's, dozens of users like me out there were scratching their heads, even for YEARS... Mystery is now solved I guess.

This being said, I'm moving now on to real use of these puppies...