Low-Speed Oscillator on STM32F746

[jerry2]

Posted on December 07, 2016 at 19:37

I've got a development board based on the STM32F746 from Mikroelektronika. The board has a 32.768 kHz crystal connected to the LSE oscillator pins. I can't get the oscillator to start and come ready.

Here's my code--any idea what I'm doing wrong?

/*

 * Start the LSE (32 kHZ) oscillator

 */

    RCC->APB1ENR |= RCC_APB1ENR_PWREN;        // enable PWR interface clock

    PWR->CR1 |= PWR_CR1_DBP;                                  // disable backup domain write protection

    RCC->BDCR |= RCC_BDCR_BDRST;                        // reset backup domain

    RCC->BDCR &= ~RCC_BDCR_BDRST;                    // deassert backup domain reset

    RCC->BDCR |= RCC_BDCR_LSEON;                        // enable LSE oscillator

    while(!(RCC->BDCR & RCC_BDCR_LSERDY))

                 ;                                                                             // wait for LSE ready

    RCC->BDCR &= ~(0b11 << 8);                                      //

    RCC->BDCR |= 0b01 << 8;                                            // select LSE as RTC clock

    RCC->BDCR |= RCC_BDCR_RTCEN;                        // enable RTC

[waclawek.jan]

Posted on December 07, 2016 at 20:06

How do you know that LSE is not running?

Have a look also at

https://community.st.com/0D50X00009XkaBaSAJ

JW

[Tesla DeLorean]

Posted on December 07, 2016 at 20:19

Does the F7 have the write buffer hazard with respect to you enabling a clock, and then immediately trying to write to the peripheral? (Check Errata)

I'd probably fence those first two writes.

[ST Renegade]

Posted on December 07, 2016 at 22:21

Hi Jerry,

as usual I'm going to advise you to use the STM32CubeMX tool. The code should be functional. Try to run it, and if it works, compare your code with the one generated with yours + check the ref manual etc. for details why it's done this way etc...

Good luck,

Renegade

[jerry2]

Posted on December 07, 2016 at 22:17

I don't know whether it's actually running. I'm inferring that it is if the LSERDY bit in the BDCR register comes on. I never see this bit getting set--the while loop never exits.

[jerry2]

Posted on December 07, 2016 at 22:17

I don't think that's the problem. The issue persists even when I single-step the code in the debugger.

[Tesla DeLorean]

Posted on December 07, 2016 at 22:29

This I'll presume is with 

Mikroelektronika's MikroC? Is it handling the volatile nature of peripheral registers properly? Can you turn optimization off?

[jerry2]

Posted on December 07, 2016 at 22:52

No, it's Rowley Crossworks with GCC. I checked and all the peripheral registers related to this issue are properly declared volatile. All optimizations are off.

[Tesla DeLorean]

Posted on December 07, 2016 at 22:57

And does LSERDY assert in BDCR or not? What I'm reading suggests you see it in the debugger, but not your loop.

If you never see LSERDY assert you need to look at the external hardware, and probe with a scope, or pipe LSE to MCO or TAMPER, or wherever it gets emitted on the F7.

If LSERDY asserts in the register but your code doesn't see it, then you'll need to review a disassembly of the offending code to understand why.

[jerry2]

Posted on December 07, 2016 at 23:12

LSERDY never asserts in BDCR. Time to probe with a scope... Just wanted to make sure first that I wasn't doing something stupid in the code. I have very similar code for a few STM32F4 boards I have and it works just fine on them.