Clock calendar implementation on RTC

LeafLabs Garden » Community » The Garden

Clock calendar implementation on RTC

(152 posts) (17 voices)

Started 4 years ago by howrupravin
Latest reply from bubulindo

« Previous 1 234…11 Next »

Rod
Member

Its not actually necessary to turn on the HSE on the STM32. The chip comes up using the HSI which is already pretty accurate.

In Maple the HSE is turned on in rcc.c in rcc_clk_init() which is called from init() which is explicitly called in the test programs as in:

// Force init to be called *first*, i.e. before static object allocation.
// Otherwise, statically allocated objects that need libmaple may fail.
__attribute__((constructor)) void premain() {
init();
}

which, of course, I copied from another example without understanding it in depth...

So, you are right, the HSE is already going and I hit the on switch again. Shouldn't actually be a problem, though.

I don't see any mention of the LSE in the rest of Maple, which makes sense as there is is no 32K crystal (on the Maple Mini at least).

On the Maple Mini the pins used to connect the crystal are actually configured and used as I/O pins (PC14/PC15).

It seems quite likely that something special needs to be done via AFIO to set these pins up for the LSE.

When you say hangs polling for clock ready, you mean 'HSE ready' and 'LSE ready' as well, right?

Posted 4 years ago #
bubulindo
Member

No, the HSE ready bit works well. I have noticed that I need to power off the board to change RTC clock. But after that it works perfectly.
The LSE however, doesn't seem to work.

As far as pins go, in the manual it says that the LSE takes priority over the pins and nothing else. I'll try changing the pins to high impedance, or change the init function to disregard PC14 and 15. Apart from that I really don't see any other thing that can cause this apart from a hardware problem.

Posted 4 years ago #
bubulindo
Member

I had a look at it and seems that the pins are only changed when you call pinMode() to it. So this shouldn't be the problem. Either way I slashed out the functions related to the pins and the result was the same. :\

So I'm putting this down to hardware. :(

By the way, one thing I notice is that by including time.h, the link to wirish.h gets broken. It's impossible to include both. Any reason why and how to bypass that behavior?

Maybe when you get your board we can check if this is a crystal or software problem.

Posted 4 years ago #
Rod
Member

Here's a thought...

I can take 3 seconds to have the LSE clock stabilize. Are you doing things in a way that that might be an issue?

Also, I'm surprised that you have to reset (you actually said power off. Presumably the chip behaves the same with a power off as it does when you push the reset switch.) to change the RTC clock source. The manual says you have to reset the backup domain, but I did that in rtc_init().

Posted 4 years ago #
Rod
Member

Looks on the schematic for your board that the 32kHz crystal is connected to the correct pins on your board. Also appears that all you need to do to connect the crystal to the oscillator is to turn on the LSE with LSEON as we are doing.

I ordered my board from Optimal Microsystems who claims to be 'the' Olimex distributor in Canada. Status is not stock, but 'coming soon'. So it may be a while coming.

ST's standard peripheral library (V3.2) just sets the LSEON bit in the BDCR, but they do make a point of clearing LSEBYP in the same register, which is a good point. (Their code is just terrible....)

Wait, I think I may have the issue...

In Rtc_init() :

case RTCSEL_LSE:
rcc_start_lse();
RCC_BASE->BDCR = RCC_BDCR_RTCSEL_LSE;
break;

The LSEON bit is in the BDCR register, so setting the clock source is clearing the on bit....

Want to swap the two lines and let me know if it works then?

Posted 4 years ago #
bubulindo
Member

Good point, swapping the lines did nothing and changing the selection instruction with a bb_peri_set_bit to set bit 8 in BDCR also did nothing.

I also added an instruction to clear LSEBYP just before turning LSEON on, just in case.

Posted 4 years ago #
Rod
Member

How about time delays after the bkp_init() and bkp_enable_writes() of a couple of seconds each?

LSEON is in the backup domain. It could be that we need to be synchronzed.

Every other access to the backup domain has a

rtc_clear_sync();
rtc_wait_sync();
rtc_wait_finished();

in front of it. Maybe RTOFF is or the sync flag isn't getting set before we try and write.

Posted 4 years ago #
bubulindo
Member

You lost me here.

Are you sure LSEON is in the backup domain? From the manual the RTOFF flag is only important when we are writing to the RTC registers. All the others haven't got that problem.

Posted 4 years ago #
Rod
Member

Yes, it sounds odd, but there is a note in the reference manual that says that specifically.

My thinking is that the backup domain reset that is required in order to change clock sources takes a while and probably requires an interface reset.

I'd post references, but this is from my iPhone.

Posted 4 years ago #
bubulindo
Member

I tried using

rtc_clear_sync();
rtc_wait_sync();
rtc_wait_finished();

in front of it, but got the same result.
I think we got to the point where the hardware fault is more and more likely and testing another board should be best before I pull my hair out. LOL

Posted 4 years ago #
Rod
Member

You have been very patient and persistent. Much appreciated.

My sense is that we are close, though. Pretty hard to debug remotely like this.

The note I was referring to is at the top of section 7.3.9 - Backup domain control register in RCC.

Did you try the delays? Its got to take a while to reset all the backup domain registers, I would think.
One needs to turn off the write protect bit after that. Have a look and see what you think.

Posted 4 years ago #
Rod
Member

I was 10 days over Christmas trying to get the dang thing to even tick.

I'm still turning up things done wrong, so I haven't quit yet...

Would be nice if LeafLabs built a board with the 32 kHz crystal on it. The low power stuff is a big deal and you can't do it without the 32 kHz crystal and the RTC.

Posted 4 years ago #
bubulindo
Member

Yes, Just tried adding a 3 second delay after and before enabling the backup writes but no luck. If something takes that long to "sync", shouldn't there be a flag to notify that it is ready?

Here's an interesting behavior, I tried this code as a setup:

//lse clock setup
bkp_init();
delay(3000);
bkp_enable_writes();
delay(3000);
//RCC_BASE->BDCR &= ~RCC_BDCR_RTCSEL;
RCC_BASE->BDCR = 0;//clear everything

bb_peri_set_bit(&RCC_BASE->BDCR, RCC_BDCR_LSEON, 1);//start clock

delay(3000);

if (bb_peri_get_bit(&RCC_BASE->BDCR, RCC_BDCR_LSEON) == 1){digitalWrite(BOARD_LED_PIN, HIGH);}
while (bb_peri_get_bit(&RCC_BASE->BDCR, RCC_BDCR_LSERDY_BIT) == 0); //error...
digitalWrite(BOARD_LED_PIN, LOW);
bb_peri_set_bit(&RCC_BASE->BDCR, BIT(8), 1); //setting the bit
//RCC_BASE->BDCR = RCC_BDCR_RTCSEL_LSE;
*bb_perip(&RCC_BASE->BDCR, RCC_BDCR_RTCEN_BIT) = 1; // Enable the RTC
rtc_clear_sync(); //why??
rtc_wait_sync();
rtc_wait_finished();

and the LED never came on. Should this point us towards somewhere?

P.S.: I basically got rid of all the setup functions and wrote the sequential code in a function inside the IDE. That way it is easier to see where the problem is and not to spread changes around.

Posted 4 years ago #
Rod
Member

if (bb_peri_get_bit(&RCC_BASE->BDCR, RCC_BDCR_LSEON) == 1){digitalWrite(BOARD_LED_PIN, HIGH);}

should be:

if (bb_peri_get_bit(&RCC_BASE->BDCR, RCC_BDCR_LSEON_BIT) == 1){digitalWrite(BOARD_LED_PIN, HIGH);}

Before that:

bb_peri_set_bit(&RCC_BASE->BDCR, RCC_BDCR_LSEON, 1);//start clock

is actually setting the ready bit rather than starting the clock I think...

I've noticed before that stuff never works until I believe that it can...

You haven't yet convinced me of your bad solder joint... ;)

Posted 4 years ago #
bubulindo
Member

I wouldn't say bad solder joint... but the RTC capacitance may be off.

WTF?!?!?!?

It is running.
Had another look at that bb_peri_bit and the BIT part was in fact missing. After that was set, it started moving. Yeay.

Next, I'll see if I can nicely wrap this into a library. :)

Want me to send you my files so you can upload into github and get the working version for this board?

Thanks for your invaluable help.

Posted 4 years ago #

RSS feed for this topic

« Previous 1 234…11 Next »

Reply »

You must log in to post.