Nucleo-F767ZI : RTC is not working

alexandre23 · ‎2016-07-18

Posted on July 18, 2016 at 17:33

Hello,

Just executing STM32Cube_FW_F7_V1.4.0/Projects/STM32F767ZI-Nucleo/Examples/RTC/RTC_Calendar, the RTC never initialise.

The function RTC_EnterInitMode return an error because

RTC_ISR_INITF bit never raise.

We use RTC on our projects on F4 and F74x without any trouble, the problem is only with F767. (exact same program run fine with nucleo F746)

I have also tried to use RTC with the Chibios RTOS, and i have the same problem : RTC_ISR_INITF bit never raise.

I have tried to connect RTC to LSE and LSI, with no success

I have check the F767 errata, but there is nothing about RTC misbehaviour.

Any insight to help me to resolve this problem ?

Thanks

Alexandre

#f767-rtc

Tesla DeLorean · ‎2016-07-18

Posted on July 18, 2016 at 17:54

The Nucleo boards typically don't have LSE placed

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..

Christopher Pappas · ‎2016-07-18

Posted on July 18, 2016 at 18:11

I have both Nucleo-144 boards F767ZI and F746ZG. They each have an LSE 32khz xtal on board. I ran the v1.4.0 RTC examples on both, and they work ok here. Once the code runs for the first time, the initialization routine writes to a location in BBRAM, and will not run again unless the power is removed from VBat, or the BBRAM contents is lost. The only way this would not work is if the jumpers on the board have been altered, or the components have been damaged. Can everybody else give these RTC examples a try on their Nucleo-144 boards?

Nesrine M_O · ‎2016-07-19

Posted on July 19, 2016 at 12:14

Hi Alexandre,

I tested the example STM32Cube_FW_F7_V1.4.0/Projects/STM32F767ZI-Nucleo/Examples/RTC/RTC_Calendar using the STM32F767 Nucleo board and it works as expected.

Please be sure about your board settings.

-Syrine-

alexandre23 · ‎2016-07-19

Posted on July 19, 2016 at 23:58

Thanks for all your answers.

If RTC is not flawed on STM32F76x series, it's a good news for us since our goal is not nucleo, but replacing STM32F746 by STM32F767 on an UAV autopilot to be able to use the 64 bits floating point unit.

Why RTC is not working on the two nucleos that i own stay a mistery for me, as i have no problem running the same source code on nucleo F746, and none of my nucleo are moded.

perhaps it's my toolchain wich is faulty, so perhaps one of you can try to flash the attachen .bin to your nucleo to see if green led is blinking, if yes, the problem is with my nucleo, if no, the problem is with my toolchain.

On the other side, one can send me a working binary that i could flash on my own nucleo.

Thanks again.

Alexandre

________________

Attachments :

NUCLEOF767_rtc_blink.bin : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hzjr&d=%2Fa%2F0X0000000bRN%2Ffm.aKk7l8x7jiEz1YN1lURsv3uNI1UNMVO3Ks90XbGE&asPdf=false

Christopher Pappas · ‎2016-07-19

Posted on July 20, 2016 at 03:51

I flashed your bin file onto my 767ZI board. On cold reset, I see no leds on or flashing. if I try to step into code @08000000 with the ST-Link debugger, I get lost communication. This usually means there is a hard fault happening, or the system clock is not getting configured properly, and the code is just frozen waiting for HSE to ''wake up''.

I attached a .hex file here of the ''RTC_Calendar'' example compiled on KEIL with all the latest software updates and packs installed. Flash it to your board. You should see the red led on the first time you run it. then hit the reset button, and you will see the blue led on as well, indicating the initialization ran ok and the RTC is using the previous stored values in BBRAM.

________________

Attachments :

STM32F767ZI-Nucleo.hex : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hzwf&d=%2Fa%2F0X0000000bRK%2FfZycfz42bTKGUBbcY7ZHc1cagNDEscmXHAqbynyIS4Y&asPdf=false

alexandre23 · ‎2016-07-20

Posted on July 20, 2016 at 11:31

if I try to step into code @08000000 with the ST-Link debugger, I get lost communication.

It's normal because code is done to be flashed in ITCM memory @ 0x00200000.

I have been trying to flash your .hex, but since i rip stlink from my nucleo in favor of blackMagicProbe (wich run the gdb server on the probe), i am no more able to flash .hex file.

I have ordered a couple of new nucleo that i will leave with stlink, and will flash your .hex when i 'll received it.

For now, i go on holidays for 3 weeks 🙂

Thanks for all the help, and when i return and test with new nucleo, i'll do a summary of my investigations on this thread.

Alexandre

alexandre23 · ‎2016-08-29

Posted on August 29, 2016 at 17:10

Hello.

I found the origin of my problem.

As i have already told, my main environment is quite different from what most of the forumers use : chibios RTOS and gnu GCC toolchain.

I have found why it was not working with chibios :

a new bit has appeared in the RCC_APB1ENR register :

Bit 10 RTCAPBEN: RTC register interface clock enable

This bit is set and cleared by software.

0: RTC register interface clock disabled

1: RTC register interface clock enabled

and chibios was not aware of this bit, which is specific to these new family.

There is still a mystery why the ST example don't work neither compiled with GCC, because i have seen that the macro __HAL_RCC_RTC_CLK_ENABLE seems to correctly set this bit.

anyway, it works with chibios, so my problem is solve.

Thanks for the people who take time to answer me.

Alexandre