Flashing 404as? about stc_diyclock HOT 18 CLOSED

Here's the schematic of my clock.

from stc_diyclock.

Your schematic looks the same as the classic STC15F204EA which I have, so the regular build should work for you (shouldn't need to build for the other hardware variants.)
I updated the releases, and published the latest main.hex. This should not require any eeprom space as it's under 4k.
https://github.com/zerog2k/stc_diyclock/releases/tag/0.6.0

Are you using STC-ISP or stgcal to flash?

from stc_diyclock.

STGCAL. Thank you for your help!

from stc_diyclock.

I flashed main.hex to it but I'm getting a 1F:7F (flashing colon)

from stc_diyclock.

hachi had a similar issue. I see now that your DS1302 clk and rst lines dont have external pullups.
I thought this was already fixed in recent build.
#8 (comment)

Did you flash the latest main.hex i posted (0.6.0 above) or did you compile this yourself from master?

from stc_diyclock.

Both, both are coming up with 1f:7f.

from stc_diyclock.

Could it be that the time in the DS1302 chip was incorrectly stored? I had that error occur to me a few times while modifying the driver functions. But, the time values should have been reset by ds_ram_config_init() if the magic values were wrong - try removing the DS1302 battery and placing it back to force a reset by corrupting the locations where the magic values are stored.

However, since ds_reset_clock() was commented out in favor of resetting the clock via writing the values in cfg_table to the DS1302's RTC / SRAM registers in ds_ram_config_init, and I can't find the initializer for cfg_table, it could be that it's writing garbled RAM data in the 8051 to the DS1302's RTC / SRAM registers on a call to ds_ram_config_init after the DS1302 has lost power. Not sure about this last point though, might have to wait for zerog2k to comment because the table might have been initialized somewhere else I couldn't find :P - Either that, or you could try changing the time in the menu?

from stc_diyclock.

Ah, sorry, just realised from the sdcc manual that all internal ram is initialized to zero in startup code before main() runs. From the manual: "The startup code clears all internal data memory, 256 bytes by default", so writing garbled data wouldn't be an issue, as cfg_table would be all zeroes. Only thing I could think of is the RTC time registers not being reset.

from stc_diyclock.

I think even if the ds1302 rtc ram is corrupted, the way the firmware works, is that when the minute increments to next, it should roll them back into a good state. Also, if it is working, even with corrupted ram, you can set the clock.
If you cannot talk to ds1302 (example, because of pull-up issues on signal lines), then it will never be able to get/set rtc data. I suspect his might be the case.
The difference in the schematic i see here is that there is external pullup only on io line, not reset or clock. So may need to go with pin mode on mcu which gives stronger pullup than mode "00" (quasi-bidirectional mode, aka weak pullups when driven high). I think pinmode "01" (push-pull output) would give stronger pullup, and may be needed for rst/clk.

As a test, I can suggest to try this by setting P1_0 (rst) and P1_2 (clk) pinmode:
P1M0 |= (1<<ADC_LIGHT) | (1<<ADC_TEMP) | (1 << 2) | (1 << 0); // P1_0 (rst) & P1_2 (clk) push-pull output

https://github.com/zerog2k/stc_diyclock/blob/master/src/main.c#L349-L351

from stc_diyclock.

Hmm, I must admit I haven't studied how the ds1302 interface code is written. I think you're right, the weak pull ups only source 270 microamps at maximum, and might not drive the IO lines properly at those transfer rates.

If this works, it makes me wonder if compability could be increased if the IO pins driving the single directional bus lines are changed to push pull in future, just in case future boards need it? Also, might it be a good idea to start considering ways to rewrite the assembly driver to switch pin states for the pins driving the bidirectional line on the fly, driving it using push pull then switching back to a weak pull up to read the output, so that the driver works in another similar case, but without pull ups even on the I/O line?

from stc_diyclock.

I still don't think it's working properly even with that bit tacked on the end of the P1M0 line. I'm still getting the "1F:7F."

If I press the bottom button I get "13*c", "FF.FF"," - -", back to "1F:7F.".
If I press the top button ":7F", "12:00", back to "1F:7F.".

from stc_diyclock.

I can try soldering on a 10K pull up if I can trace-out where to tack it onto.

EDIT: added 10K pullups between pins 1 and 5 and 1 and 7 of the DS1302 chip. It didn't make a difference.

from stc_diyclock.

Confirmed 5v and 3v on the DS1302, double checked ground. Cheked continuity between RST, I/O and CLK between the STC15 and the DS1302. Tried using 4.7K and 10K pull ups on all 3 pins. I'm trying to find a multi-meter that can measure the 32khz crystal but I haven't found one yet.

Just ordered another clock from the vendor you provided on the main page. Maybe this DS1302 chip was damaged.

from stc_diyclock.

I assume the kit was working ok with original firmware before flashing?
Do you have a logic analyzer/scope to examine the communication on the lines?
That has me stumped. The only significant difference I have on my kits to yours is that your's (per schematic), has single 10k pullup (should be sufficient at these clock rates) on io line, and no external pullups on rst or clk. Mine has 4.7k on all 3. I have also swapped successfully between either a STC15F204EA (original) and STC15W408AS which is peripherally identical to 404AS, and these work fine for me.

maybe you can paste in the stcgal upload log here? curious about that.

from stc_diyclock.

The clocks using the sound chip (NY3P065) and the 4 digit direct drive clocks (no anode drivers) all use the single pull resistor on the I/O line, no pull ups on the RST/ or SCLK lines. I have never found them to need anything other than the default configuration bi-directional STC output pins to drive and read.

A DS1302 that is oscillating should measure approximately 2.3 volts ac across pins 2 and 3. A dead chip or crystal will read zero volts, give or take some noise.

As a test, I just flashed a clock with the current firmware. Removing the DS1302 results in a "1F:7F." display so I would expect that the RTC is not running. Dead chip, bad crystal, bad solder, etc.

from stc_diyclock.

The clock has never worked correctly. Getting .9VAC between 2 and 3. I'm getting a couple more clocks slow boating from China so we'll see what happens when they get here. I found a circuit to test the Crystal. Gonna have to wait till i'm done teaching for the daythough.

from stc_diyclock.

hi @dcorwin822 any updates on this? did a new kit solve the issue?

from stc_diyclock.

as a follow up, also found that if rtc battery is dead, the unit can start up with junk values in rtc, leading to this. I'm looking at adding some validation/bounds-checking in rtc_init, but might be easiest to just manually attempt to set the clock if in this state.

from stc_diyclock.