Fix for issue #4452 - time.sleep on STM #6303
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Issue #4452. In stm32_peripherals_rtc_set_alarm(), if the STM chip has a high-speed crystal, the value of rtc_clock_frequency is 32000. The SubSeconds calculation in line 185, however, will overflow whenever (raw_ticks % TICK_DIVISOR) is > 1000. The multiplication by 32 will give a value > rtc_clock_frequency. Since alarm.AlarmTime.SubSeconds is an unsigned 32-bit int, the result will wrap around and the sub-seconds time calculation will be very incorrect. The fix is to adjust the calculation by adding rtc_clock_frequency back to SubSeconds if the calculation has wrapped.
Note that a possibly related issue at line 89 in stm32_peripherals_rtc_init() could have resulted in an extended loop, the "while" has been changed to an "if" to make sure that no more than two reads of the SSR take place.
Testing with the script from issue #4452 gives the following output:
Which is much improved over the initally reported results.