STM32 RTC – How RTC Keeps Time Accurately Using LSI as Clock Source

56.00 kHz is 1 MHz / 17.86. That means a simple integer divider can only hit 1 MHz / 17 = 58.82 kHz or 1 MHz / 18 = 55.56 kHz. If you can't change the 1 MHz clock (very slow for a normal microcontroller) and can only divide it by a integer, then no, you can't get 56.00 kHz.

There are several options:

1. Use a different clock frequency. Find some integer multiple of 56.00 kHz that is otherwise acceptable and use that. For example 7 MHz / 125 works out exactly.

2. Do dithering. If you can accept a little jitter, then you can hit any frequency long term. In this case you'd have to jitter between 17 and 18 cycles of 1 MHz. That will be difficult in most micros just because there won't be enough cycles to make the next period value and load it into a hardware counter. However, this technique could work with any frequency that provides enough cycles. A higher input frequency also results in less jitter, since the jitter is always one cycle of the input clock. For example, with a 10 MHz clock you jitter between 178 and 179 cycles. That is enough cycles to be doable on most micros, although you'd probably still have to code it carefully and pay attention to individual instructions.

3. Some micros have fancy clock generators built in that effectively do the jitter algorithm in hardware. Some of the new low end PIC 16F1xxx have such a peripheral, but I don't remember its name off the top of my head.

4. Use a external oscillator, possibly with PLL multiplier and a divider.

Yes, and if you use the LSE clock, everything is fine. This blurb is telling you that if you choose an alternate clock source for the RTC, such as HSE or LSI you will NOT be fine.

A lot of applications just need to keep track of runtime, and so don't have a 32k crystal or anything like that to maintain time across power cycles. For THOSE applications, LSI or HSE clock sources are adequate. It sounds like that's not a good way to go for you though.