cancel
Showing results for 
Search instead for 
Did you mean: 

Can the RTC's calendar function be used alongside BLE?

burn_
Associate III

Hey folks,

I'm having issues with the RTC's calendar function while using BLE.

I would like to timestamp recorded data using the calendar function of the RTC and then transmit that data over Bluetooth. However, when I enable the Bluetooth middleware in Cube, it forces the ASYNC and SYNC prescalers of the RTC to predetermined values of 0xF and 0x7FFF, respectively. See image.0693W000004KVwMQAW.pngIs it possible to use the calendar function while using BLE? If so, how?

Thus far I found the following in app_conf.h (which is not very encouraging...) :

#define CFG_RTCCLK_DIVIDER_CONF 0
 
#if (CFG_RTCCLK_DIVIDER_CONF == 0)
/**
 * Custom configuration
 * It does not support 1Hz calendar
 * It divides the RTC CLK by 16
 */
#define CFG_RTCCLK_DIV  (16)
#define CFG_RTC_WUCKSEL_DIVIDER (0)
#define CFG_RTC_ASYNCH_PRESCALER (CFG_RTCCLK_DIV - 1)
#define CFG_RTC_SYNCH_PRESCALER (0x7FFF)

Is there a way to make the two work alongside each other?

1 ACCEPTED SOLUTION

Accepted Solutions
burn_
Associate III

Just as a follow up to my original question:

Changing CFG_RTCCLK_DIVIDER_CONF from 0 to 16 worked i.e.

 #define CFG_RTCCLK_DIVIDER_CONF = 16

I can still use Bluetooth functionality and my RTC has a one second tick.

Thanks @Remi QUINTIN​  for setting me on the right track.

View solution in original post

5 REPLIES 5
Remi QUINTIN
ST Employee

In fact, this fixed configuration is not linked to the fact the BLE feature is added. It is always the case. We are looking for making it more flexible.

But this configuration is considered to be the most optimal one to use the calendar and a real time server.

Note that all our applications are using a time server by default. Hence the proposed fixed values.

You can use other values, but they won’t be optimal.

In the meantime, the quickest way to cope with this “limitation�? is to write your own values directly in the app_conf.h file.

Just #define CFG_RTCCLK_DIVIDER_CONF not 0 and define your own values.

The drawback of doing this way is that you will have to modify the app_conf.h file each time you modify the system configuration using CubeMX.

burn_
Associate III

Thank you @Remi QUINTIN​  for you response - glad to hear that it is being looked into. When you say "optimal", are you referring to power consumption of the MCU or are you suggesting that some applications may not work as intended?

My proposed workaround would then be to change it to this:

 #define CFG_RTCCLK_DIVIDER_CONF = 16

See below the expanded code snipped from app_conf.h and the RTC block diagram from the reference manual below.

/******************************************************************************
 * Timer Server
 ******************************************************************************/
/**
 *  CFG_RTC_WUCKSEL_DIVIDER:  This sets the RTCCLK divider to the wakeup timer.
 *  The higher is the value, the better is the power consumption and the accuracy of the timerserver
 *  The lower is the value, the finest is the granularity
 *
 *  CFG_RTC_ASYNCH_PRESCALER: This sets the asynchronous prescaler of the RTC. It should as high as possible ( to ouput
 *  clock as low as possible) but the output clock should be equal or higher frequency compare to the clock feeding
 *  the wakeup timer. A lower clock speed would impact the accuracy of the timer server.
 *
 *  CFG_RTC_SYNCH_PRESCALER: This sets the synchronous prescaler of the RTC.
 *  When the 1Hz calendar clock is required, it shall be sets according to other settings
 *  When the 1Hz calendar clock is not needed, CFG_RTC_SYNCH_PRESCALER should be set to 0x7FFF (MAX VALUE)
 *
 *  CFG_RTCCLK_DIVIDER_CONF:
 *  Shall be set to either 0,2,4,8,16
 *  When set to either 2,4,8,16, the 1Hhz calendar is supported
 *  When set to 0, the user sets its own configuration
 *
 *  The following settings are computed with LSI as input to the RTC
 */
#define CFG_RTCCLK_DIVIDER_CONF 0
 
#if (CFG_RTCCLK_DIVIDER_CONF == 0)
/**
 * Custom configuration
 * It does not support 1Hz calendar
 * It divides the RTC CLK by 16
 */
#define CFG_RTCCLK_DIV  (16)
#define CFG_RTC_WUCKSEL_DIVIDER (0)
#define CFG_RTC_ASYNCH_PRESCALER (CFG_RTCCLK_DIV - 1)
#define CFG_RTC_SYNCH_PRESCALER (0x7FFF)
 
#else
 
#if (CFG_RTCCLK_DIVIDER_CONF == 2)
/**
 * It divides the RTC CLK by 2
 */
#define CFG_RTC_WUCKSEL_DIVIDER (3)
#endif
 
#if (CFG_RTCCLK_DIVIDER_CONF == 4)
/**
 * It divides the RTC CLK by 4
 */
#define CFG_RTC_WUCKSEL_DIVIDER (2)
#endif
 
#if (CFG_RTCCLK_DIVIDER_CONF == 8)
/**
 * It divides the RTC CLK by 8
 */
#define CFG_RTC_WUCKSEL_DIVIDER (1)
#endif
 
#if (CFG_RTCCLK_DIVIDER_CONF == 16)
/**
 * It divides the RTC CLK by 16
 */
#define CFG_RTC_WUCKSEL_DIVIDER (0)
#endif
 
#define CFG_RTCCLK_DIV              CFG_RTCCLK_DIVIDER_CONF
#define CFG_RTC_ASYNCH_PRESCALER    (CFG_RTCCLK_DIV - 1)
#define CFG_RTC_SYNCH_PRESCALER     (DIVR( LSE_VALUE, (CFG_RTC_ASYNCH_PRESCALER+1) ) - 1 )
 
#endif
 
/** tick timer value in us */
#define CFG_TS_TICK_VAL           DIVR( (CFG_RTCCLK_DIV * 1000000), LSE_VALUE )

0693W0000058yXQQAY.pngChanging CFG_RTCCLK_DIVIDER_CONF to 16 would mean that CFG_RTCCLK_DIV remains 16, therefore not affecting the CFG_TS_TICK_VAL timing. In addition, the CFG_RTC_ASYNCH_PRESCALER remains the same (value of 15). Effectively, only the CFG_RTC_SYNCH_PRESCALER is modified to a value that produces a 1 Hz clock for the calendar functionality. As far as I can tell from the block diagram, nothing but the calendar (and maybe RTC_CALIB) should be affected by this change.

Could anyone verify my logic? Or am I perhaps missing something?

burn_
Associate III

Just as a follow up to my original question:

Changing CFG_RTCCLK_DIVIDER_CONF from 0 to 16 worked i.e.

 #define CFG_RTCCLK_DIVIDER_CONF = 16

I can still use Bluetooth functionality and my RTC has a one second tick.

Thanks @Remi QUINTIN​  for setting me on the right track.

LWChris
Associate III

As a side note, when you compare the resulting values for CFG_RTCCLK_DIVIDER_CONF = 0 vs 16, you will find that for 16 the calculations yield the same values for all defines, except for CFG_RTC_SYNCH_PRESCALER:

#define CFG_RTCCLK_DIVIDER_CONF 0
 
#define CFG_RTCCLK_DIV (16)
#define CFG_RTC_WUCKSEL_DIVIDER (0)
#define CFG_RTC_ASYNCH_PRESCALER (0x0F)
#define CFG_RTC_SYNCH_PRESCALER (0x7FFF)
#define CFG_RTCCLK_DIVIDER_CONF 16
 
#define CFG_RTCCLK_DIV CFG_RTCCLK_DIVIDER_CONF
#define CFG_RTC_WUCKSEL_DIVIDER (0)
#define CFG_RTC_ASYNCH_PRESCALER (CFG_RTCCLK_DIV - 1)
#define CFG_RTC_SYNCH_PRESCALER (DIVR( LSE_VALUE, (CFG_RTC_ASYNCH_PRESCALER+1) ) - 1 )

Doing the calculations, CFG_RTC_SYNCH_PRESCALER will be calculated to become 2047 = 0x7FF.

To get around the drawback of having to update the value every time you generate code from CubeMX, you can use the "FreeRTOS_Defines" User-Code-Section:

/* USER CODE BEGIN FreeRTOS_Defines */
#undef CFG_RTC_SYNCH_PRESCALER
#define CFG_RTC_SYNCH_PRESCALER (0x7FF)
/* USER CODE END FreeRTOS_Defines */

Or, you can do it the way I did it and re-define ALL of the macros to look like they would be if it said CFG_RTCCLK_DIVIDER_CONF = 16 at the top:

/* USER CODE BEGIN FreeRTOS_Defines */
#undef CFG_RTCCLK_DIVIDER_CONF
#undef CFG_RTCCLK_DIV
#undef CFG_RTC_WUCKSEL_DIVIDER
#undef CFG_RTC_ASYNCH_PRESCALER
#undef CFG_RTC_SYNCH_PRESCALER
#undef CFG_TS_TICK_VAL
#undef CFG_TS_TICK_VAL_PS
 
#define CFG_RTCCLK_DIVIDER_CONF     16
#define CFG_RTCCLK_DIV              CFG_RTCCLK_DIVIDER_CONF
#define CFG_RTC_WUCKSEL_DIVIDER     (0)
#define CFG_RTC_ASYNCH_PRESCALER    (CFG_RTCCLK_DIV - 1)
#define CFG_RTC_SYNCH_PRESCALER     (DIVR( LSE_VALUE, (CFG_RTC_ASYNCH_PRESCALER+1) ) - 1 )
#define CFG_TS_TICK_VAL             DIVR( (CFG_RTCCLK_DIV * 1000000), LSE_VALUE )
#define CFG_TS_TICK_VAL_PS          DIVR( ((uint64_t)CFG_RTCCLK_DIV * 1e12), (uint64_t)LSE_VALUE )
/* USER CODE END FreeRTOS_Defines */

Hello!
In STMCubeMX you can set the CFG_RTCCLK_DIVIDER_CONF value in the BLE settings. This way you don't have to redefine its value for each code generation. I attached a picture of the setting option.

Képkivágás.PNG

Hope I could help!

Sincerely, Ferenc Braun