Can't flash. Stuck on "Waiting for MCU, please cycle power"

[MarqueIV]

Hoping you have some pointers for me here. I'm using the DIY kit that uses the STC 15F204EA chip and I'm using Adafruit's FTDI Friend cable in its default configuration which simply emulates a USB-to-Serial cable.

However, no matter what I try, I can't get it to download the firmware. I've tried running on a Mac, Windows 10 and Linux, I've tried 11k and 22k clock speeds, I've tried specifying 9600baud for the connection. I've tried yanking the power pin only, the TX pin only, the ground pin only, yanking them all at the same time, but no matter what, I can't get past the 'Waiting' message. What the heck am I doing wrong?

Note, I also tried the Windows app, but that just visually hung when I clicked 'Download'. I could stop it (the button to cancel was still enabled) but nothing happened.

[MarqueIV]

Anyone? Anyone? Bueller? Bueller? Bueller?

[zerog2k]

1. Do you know if your clock kit is identical in schematics to the examples we have listed on this repo? If not, I would recommend trying to setup a minimum barebones mcu on a breadboard, and seeing how that changes things.
2. can you provide a screenshot of the stc-isp tool in the "hung" state you described?
3. can you provide a detailed log of the issue you are having when programming? hint: you can see what the stcgal command is running (options, etc) when you run make flash and play around with those options, e.g. debug/verbose output so we can see what is happening.

In my experience, usually cycling ground on the clock allows the programming process to proceed. Not sure what might be happening here.

[MarqueIV]

Hi! Not sure if you saw my other posts on STCGAL's repo, but I'm currently trying it directly on a breadboard. I wanted to remove the clock itself as a point of failure.

As for what I've tried, I've pretty much played with every option listed in the makefile... baud rate, clock speed, protocol, USB adapter, tried both the tty and cu versions of the adapters, tried STCGALPROT ?= stc15a, stc15 and auto, all of them, either directly on the command line or by editing the file. Each time it's the same thing... 'Waiting for MCU, please cycle power'

As for the hardware, I've tried Adafruit's FTDI Friend, a board with CP2102, one with CH340 and one with PL2303. As for the chip itself, I've tried it in the clock, on a breadboard only hooking up VCC, Ground, TX and RX and in both cases I've tried connecting/disconnecting power by itself, ground by itself, all four at the same time (thanks to a four-pin header wire). I'm about to try adding 1K resistors in series with the TX/RX pins, then shorting out power/ground to ensure there's no phantom power here, even though yanking ground should've addressed that anyway.

I like to think I've been pretty thorough, but it still just sits there on 'Waiting for MCU, please cycle power' until I Control-C and cancel it.

That said, not sure how to run verbose mode. What's the switch for that?

[MarqueIV]

Hey... any chance we could do simple screen-sharing here? I'd even be willing to PayPal you a few bucks for your time. This is just so damn frustrating!! I'm getting to the point of just abandoning STC's chip and throwing in an Atmel either via a daughter card (cleaner) or simply severing, then re-soldering jumpers to the correct pins. At least I know that will work without issue.

[zerog2k]

https://github.com/grigorig/stcgal#usage run stcgal directly w/ --debug (you can see the stcgal commandline invokation template from make flash)

please paste a full output of stcgal output here (e.g. you can paste into http://gist.github.com and put a link to it here)

Did the clock work completely with pre-flashed clock firmware, especially interested if both buttons work, as they are serving dual duty on the uart tx & rx lines. (There is a possibility that some line/pin might have gotten fried, e.g. ESD?)

we can do a chat on https://gitter.im/zerog2k/stc_diyclock

edit: on mac, depending on chipset of uart adapter, you would have something like /dev/tty.usbserial.... or something along those lines. FTDI clones should work ok afaik, but I do recall from memory that fake (most chinese) pl2303 chipset don't work well (may have crippled osx driver). CP2102 always works fine for me on mac and linux... I have a ton of these... I think CH340G wont work well, on some platform (linux?) due to need for (uncommon) serial parity settings which arent properly implemented, which STC chips use for programming. I would review this issue on stcgal for some issues and ideas: https://github.com/grigorig/stcgal/issues/8

Alternative. Can you use wine on linux or mac? It's not pleasant but I'm able to use STC-ISP ok from wine on either of these.

[zerog2k]

I have also pulled in the latest stcgal code, as I see there were a few bugs fixed in past months. Please pull latest to get it.

[zerog2k]

oh and on mac w/ cp2102 adapter these are the settings which worked for me: STCGALOPTS="-l 9600 -b 9600" STCGALPORT=/dev/tty.SLAB_USBtoUART make flash (both handshake and transfer speeds had to be 9600, else it would never work for me on mac - linux worked at other speeds just fine)

[MarqueIV]

Not near the chip right now so I'll have to get back to you about the debug output, but I can say the stock firmware runs fine. Both buttons work. Granted, the firmware itself is horrible, but we both know that. That's why I'm desperate to get yours on there! :)

As for adapters, I know my FTDI isn't a clone because it's made by Adafruit and I'm pretty sure they sourced them from the OEM, not a Chinese supplier. But... if you say CP2102 works, and with those settings, I'll definitely try that next... with the debug options.

One question though... do you flash with it still in the clock, or on a breadboard directly? If the latter, what's the wiring setup you use, or are the four connections enough?

I ask because for AVR chips, you can't flash them directly on a breadboard without adding a crystal for timing. I didn't see any such thing in the data sheet for this chip. But I also thought I remembered seeing this chip, unlike the AVRs, has a clock source built in.

Anyway, as soon as I'm in front of the chip again, I'll test (after I've pulled the latest as you've mentioned.)

[zerog2k]

I flash them in the clock. I have set the option for reset pin, and I have wired up dtr to reset - just speeds up the development/flash cycle, but for most folks, just cycling ground connection is sufficient. Regarding breadboards, afaik, these STC chips only use internal RC oscillator. Not sure it's even possible to use an external clock source on them?

(I have temporarily "bricked" a few atmega chips by playing with fuses and messing up oscillator settings, requiring a crystal/resonator/clock pulse source to get it running again ;) )

[MarqueIV]

Ok, this is just weird!

As I said in the comments of the issue I filed on STCGAL's page (which I've now closed), I was able to get this to flash by reversing the TX/RX lines, which makes no sense to me. Now, TX on my USB-to-Serial adapter is connected to TX on the clock (and RX to RX) which, unless I'm mistaken, is backwards as the USB serial adapter is supposed to transmit (i.e. TX) to the receiver (i.e. RX) on the clock. But that's not what's happening here.

Anyway, now I have a new problem. The flash happens just fine (either in the clock or on a dedicated board) but now the firmware is borked. I get F.F on the screen and it just buzzes. Checking out your source code, I noticed you've accounted for a few different versions of the hardware, but I'm not sure mine is one of them as I tried both passing HW_MODEL_C via Make as well as defining it directly in main.c, but same result. (I also tried HW_MODEL_B even though I didn't see it referenced, but that didn't work either.)

For reference, here's my clock...

https://www.amazon.com/gp/product/B00NEEJI52/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1

I also ordered this second version...

https://www.amazon.com/gp/product/B06ZZNBFMB/ref=oh_aui_detailpage_o03_s00?ie=UTF8&psc=1

...but I haven't opened the package yet.

Question... in an attempt to perhaps write my own version of the firmware, can you tell me the bare minimum needed to Illuminate a single segment of the clock, with no other code (no timers, temp, etc.) Just light one segment? If this was an ATMEL chip, it would be cake, but I don't know this chip so I don't know how to do things like set pullups/downs, change pin direction, etc.

And lemme know if I should move this to a new issue since technically again, I can now flash.

[zerog2k]

Glad to see you were able to clear a major hurdle. Regarding tx/rx, check which actual mcu port pins these are connected to. Txd is supposed to be connected to P3.1 and rxd P3.0. It's possible they made a mistake on the pcb silkscreening, or maybe they were trying to "help" you or whomever in connecting the pins to the right pins on some uart adapter. Regarding the hardware model, do you have a schematic of your unit you can share? Regardless, I would suggest reviewing the schematics in the docs folder to see some of the variations. You can review this thread for info about HW_MODEL_C and what it represents. (I started, relatively lately, trying to abstract all of the hardware differences into a hwconfig.h file, although it's still not quite as clean as I would like - part of this is that these different hardware kits don't have a great name to distinguish between them.) LIkely whatever differences you have on your hardware vs one of the existing models needs to be abstracted out here. Getting the hardware configuration to match up to your hardware is the first order of business.

Regarding general programming approach - this is 8051 architecture. So I would be really familiar with the STC15F204EA datasheet, as well as the SDCC user guide.

[Drummerboy458]

LwwdeMacBook-Air:Desktop lww$ stcgal -a -P stc89 -p /dev/tty.wchusbserial1410 main.ihx -D Cycling power: done Waiting for MCU: <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 57 <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 63 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 5F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 63 <- Packet data: 41 <- Packet data: 2F <- Packet data: 65 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 23 <- Packet data: 2F <- Packet data: 67 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 5F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 21 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 6F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 21 <- Packet data: 2F <- Packet data: 67 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 <- Packet data: 2F <- Packet data: 25 <- Packet data: 21 <- Packet data: 41 Someone can help me with this? It keeps reading data.And I have the same problem that stucking in Cycling power:Waiting for MCU