I have the RTC clock running, but it seems to lose about 2 minutes /12 hours.
Is this a known issue. I am not sure I see a Xtal on the CPU board - is it a synthesized clock?
I need the clock to be relatively accurate for sensor monitoring over long periods, and would prefer to not have to resync with a time server every 1/2 hoiur.
If you are using DS3231 RTC chip, then according to its data sheets:
The time-drift (slow/fast) of the clock is +/- 2 minutes in 2-years (0.2 sec in 24 Hrs).
No, this would be the native STM32H7 RTC...
Clock drift like that would be normal for such a board. Please define "relatively accurate". Relative to what?
I am using the native portenta H7 - and it's built in RTC. I presume no Xtal on the board means that it is a silicon oscillator - that is trimmed to some spec.
"Relative" to a standard 32.768kHz Xtal oscillaotr. I would like to not have to adjust the clock more than once per day.
Anyways, if as I suspect - the accuracy I am observing is normal, I will get an I2C RTC and use that instead
I spoke to arduino tech support, and they confirmed that the issue is hardware related, and affects all h7 boards.
They are creating a new revision for the board that will fix this problem, but no info as to when that will be yet.
Probably not. The H7 has selectable clock chains. It's far more likely, the RTC module has been directed to a clock derived from the on board CPU crystal.
Well, there is a crystal, 32.768khz, on the board. In the tech support call i asked whether this crystal is being used, or the on board oscillator of the cpu was being used fir the rtc clock.
I did not get a straight reply, except that what i was experiencing was present on all h7 boards, and i should just get a refund and look for another device.
My guess by that answer was that this was not a software only flaw, as that would at least have an imminent fix, and not need to wait for a new hardware revision
Oh. Then they are probably using it. The million dollar question is whether they have enabled the low power domain circuit to make it work with a backup battery (I haven't looked at the Portenta to see whether it's supported by the board...).
I looked at the schematic, and there is a SIT1532AI-J4-DCC-32.768E that seems wired correctly - right voltage and correct pin assignments (no way to check the footprints however, as they are not published).
The oscillator goes to the CPU OSC32_IN - which is also correct as per the datasheet (again footprints?). The CPU data sheet does mention that the battery supplies the RTC, the backup registers, and the backup SRAM.
The MC34PF1550A0EP Power management IC has an LICELL input - correctly wired, and a VBAT output (for low power domain), and this too is wired correctly to the VBAT input of the CPU?
Seems all good.
I will let you know what reply I get about the firmware issue
I reasked teh tech support person if this is just a firmware issue or not
I got the same problem with the RTC clock drifting too much.
The problem is that the MBED firmware is configured to use the LSI clock for the RTC, which is not accurate. To use the external 32KHz oscillator, the LSE clock source should be used.
The first approach to switch from LSI to LSE in software did not prove to be successful. The 512Hz RTC calibration output was clearly showing the right frequency after switching to the LSE clock. But the time was still drifting!! I'd like to call it Arduino voodoo.
Eventually i found out that the macro MBED_CONF_TARGET_LSE_AVAILABLE was set to 0 for the PORTENTA_H7 board. => Strange as the LSE clock is present on the board.
This flag is set automagically during the MBED core compilation. To alter the flag, the MBED board configuration must be altered and the MBED core recompiled.
cd $sketchbook/hardware/arduino-git/mbed/git checkout tag_3.1.1"target.lse_available": 1.cd $sketchbook/hardware/arduino-git/mbed/ [WSL]./mbed-os-to-arduino -a PORTENTA_H7_M7_KUL:PORTENTA_H7_M7
I have had a number of tech support calls with Arduino Support on this issue. Appartently, rev 1 of the portenta PCB had a hardware bug that the external Xtal was not wired properly, and did not work. In light of that they attached the clock to the internal 32kHz oscillator.
This was the default on Board Manager version 3.2.0, and the clock was off by 1 second per minute. My correction was to call an NTP server every 1 minute, and adjust the clock manually in that format. Worked, but obviously not ideal.
Rev 2 boards have been out for a while, and Board Manager 3.3.0 now looks to see if a functioning Xtal is available, and then uses it for the oscillator, otherwise, goes back to the internal OSC.
I can confirm that there are 0 seconds offset from an NTP server check every 6 hours (which is what I do now).
HOWEVER, 3.3.0 introduced a new bug. When power is shut down, the clock always starts at UNIX time stamp 0 (1970-01-01) - even if the RTC battery is new etc.
They are working to release an update to fix this. For now, when the software starts, I call the NTP server to adjust the time on startup.
There may be better docs in the future to allow us to compile our own MBED OS, and make our own libmbed.a file, but for now - there is nothing, and I have no idea where to start there.
I'm using 3.1.1 (best at the time of development)
See my previous post on how to compile the MBED OS.
Does all that work in windows (or just linux).
I had seen the post, but could not really follow it. Confusion on my end. It would be great if it could be done in visual studio.
If you ever get a chance to make a video might make it easier for me, and maybe others.
I managed to compile it in windows using WSL2.
I agree it's rater cryptic, but Its all the documentation I have.
Its already +3 months ago that I did the work.
I'll put it on my todo list 
Will look forward to it, thanks
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.