-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
STM32L4: Adjusting RTC Synchronisation When Using MBED_TICKLESS in RTC Mode #7695
Comments
@ARMmbed/team-st-mcd Please review |
Hi mbed-os/targets/TARGET_STM/rtc_api.c Line 272 in 1ab05c2
|
Hi @jeromecoutant, funny that you should refer to that section of code because I was looking at it last week because it generates an unused variable warning. I think I understand your point at a high level but not enough to implement anything! Switching to tickless with the RTC isn't my most important problem at the moment, I shall give your point more thought sometime soon! Thanks, Matt |
2 things:
|
In the real code we do have a loop like you suggest, although I've never seen it iterate more than once. |
Maybe add also some :
|
Any update ? |
Hi @jeromecoutant, No, this is still an issue for me although I haven't looked at it since 9 Aug. I did try everything you mentioned. I was wondering if it has anything to do with Add LPTICKER tests #8129.
Sounds suspiciously like what is happening here. |
I was deliberately leaving this issue open because it is still an issue for me. The are a number of PRs relating to the RTC stuck in the pipeline I'm hoping they will fix this. If they don't it will need investigating further. Everyday I think the PRs are about to be merged and everyday they get put back; this is tricky stuff but fingers crossed they are nearly ready! :-) |
@adbridge please reopen this issue |
This was closed internally hence this was closed accordingly. If this is still an issue we'll re-open. |
Internal Jira reference: https://jira.arm.com/browse/IOTPART-6065 |
I was hoping that #8242 would help me with this. It hasn't hasn't. I just done a quick test and delaying the RTC still causes our app to hang. |
Hi Did you see that, since 5.11.1, L4 targets are now TICKLESS by default using LPTIM ? Thx |
Hi @jeromecoutant , I'm still using the RTC because I believe it allows longer periods of deepsleep, especially since #8777. Do you think I should reconsider using the LPTIM? As things stand, I'm using tickless in RTC mode and adjusting the RTC is still a problem for me. |
OK And what about closing this issue? |
Unfortunately I don't have a simple example to hand and, while this is a problem for us, I think we can work around it and I have bigger issues to deal with at the moment. If I did have time to create a simple app I would create a RTC tickless app that could handle a button (or digital input) event. When the button was pressed I'd nudge the RTC and see what happens. Our real app gets commands from its RF interface. One of the commands is 'adjust the time'. When it receives this command it adjusts the the time in a series of 0.5 second steps. These steps are taken at each of our sampling intervals. In the code below you can see the '0.5 second step' hardcoded in the calculation of
Here's our nudge code:
|
Thank you for raising this issue. Please note we have updated our policies and |
Hey @mattbrown015, Thanks for your post and details of your code. I am currently working on the same subject and your post was very helpful. Just one question/comment: LL_RTC_IsActiveFlag_SHP() is returning the value of the SHPF bit. This bit is set to 1 when a shift operation is pending. Therefore, your while loop is not correct if you want to wait for all the shift operations are done before doing a new one. I think the same applies to LL_RTC_IsActiveFlag_RS(). This solved my issue and now delaying and advancing RTC works fine. Hope this can be helpful for you too ! Good luck and cheers, OneTwoStéph |
Hi @OneTwoSteph |
Hey @jeromecoutant, My comments were only about @mattbrown015's code he posted previously. Nothing to correct in the rep ;) Cheers, OneTwoStéph |
Hi @OneTwoSteph , Thanks for your comment, you're right of course, there's a misplaced ! in our code. Way back in August Jerome posted I've taken the ! out now but unfortunately it doesn't solve my problem, I still get stuck somewhere in the RTOS scheduler. I'm not worrying about it though because our product seems to be doing OK without this feature. Thanks, |
Description
As discussed here How to Achieve Long Periods of Deep Sleep on STM32 #7156 and here deepsleep - LPTIM1 Vs RTC on STM32? it seems appropriate to use the RTC when enabling
MBED_TICKLESS
on STM32L4.In our application we also want to use the RTC for recording the time at which a sample is taken. To achieve this our communication protocol includes a method of sending the Unix time to the device.
In an attempt to alleviate the obvious short comings of sending the Unix time via a non-deterministic transport we've also implemented a RTC synchronisation command. In other words, our protocol includes a command to adjust the time by +/-127 s although it is done in a series of 0.5 s steps.
To implement the 0.5 s time adjustment we've used the 'RTC Synchronisation' feature. With the error checking removed and various simplifications made, our code looks a bit like:
The time adjustment was originally implemented without
MBED_TICKLESS
defined and it works. It still works whenMBED_TICKLESS
is defined.The problem comes when I switch the 'lpticker' from the LPTIM to the RTC using
"target.lpticker_lptim": 0
inmbed_app.json
. In this mode something goes wrong and the application locks up when attempting to delay the RTC (I can advance the RTC).I've done a bit of debugging and it appears to be stuck in
SysTick_Handler
. My feeling is that sys tick is continually firing, it never gets cleared, and no normal code is being run. But, I don't understand how the RTC, sys tick, etc. hang together to really understand.This is pretty complicated stuff but I'd be grateful if anyone has any thoughts.
Issue request type
[X] Question
[ ] Enhancement
[ ] Bug
The text was updated successfully, but these errors were encountered: