Electronic – STM32 RTC with HAL libraries

hal-libraryrtcstm32

I am working on stm32l053 (nucleo 64) and I want to track time with integrated RTC. Since I am quite new to stm32 development I am using CubeMX and HAL libraries.

My problem is that the time is not changing over time, the HAL_RTC_GetTime() function is always returning time that was configured at the beginning in the MX_RTC_Init() function generated by CubeMX.

Here is my code for testing:
Vars:

RTC_TimeTypeDef currTime = {0};

in while

    while (1)
  {
    /* USER CODE END WHILE */

    /* USER CODE BEGIN 3 */
      HAL_RTC_GetTime(&hrtc, &currTime, RTC_FORMAT_BIN);
      char timeBuff[20];
      sprintf(timeBuff,"%d,,,%d...%d\n", currTime.Hours, currTime.Minutes, currTime.Seconds);
      HAL_UART_Transmit(&huart2, timeBuff, sizeof(timeBuff), 100);
      HAL_Delay(1000);


  }

And here is the generated MX_RTC_Init() function:

static void MX_RTC_Init(void)
{

  /* USER CODE BEGIN RTC_Init 0 */

  /* USER CODE END RTC_Init 0 */

  RTC_TimeTypeDef sTime = {0};
  RTC_DateTypeDef sDate = {0};

  /* USER CODE BEGIN RTC_Init 1 */

  /* USER CODE END RTC_Init 1 */
  /** Initialize RTC Only 
  */
  hrtc.Instance = RTC;
  hrtc.Init.HourFormat = RTC_HOURFORMAT_12;
  hrtc.Init.AsynchPrediv = 127;
  hrtc.Init.SynchPrediv = 255;
  hrtc.Init.OutPut = RTC_OUTPUT_DISABLE;
  hrtc.Init.OutPutRemap = RTC_OUTPUT_REMAP_NONE;
  hrtc.Init.OutPutPolarity = RTC_OUTPUT_POLARITY_HIGH;
  hrtc.Init.OutPutType = RTC_OUTPUT_TYPE_OPENDRAIN;
  if (HAL_RTC_Init(&hrtc) != HAL_OK)
  {
    Error_Handler();
  }

  /* USER CODE BEGIN Check_RTC_BKUP */

  /* USER CODE END Check_RTC_BKUP */

  /** Initialize RTC and set the Time and Date 
  */
  sTime.Hours = 10;
  sTime.Minutes = 15;
  sTime.Seconds = 0;
  sTime.TimeFormat = RTC_HOURFORMAT12_PM;
  sTime.DayLightSaving = RTC_DAYLIGHTSAVING_NONE;
  sTime.StoreOperation = RTC_STOREOPERATION_RESET;
  if (HAL_RTC_SetTime(&hrtc, &sTime, RTC_FORMAT_BIN) != HAL_OK)
  {
    Error_Handler();
  }
  sDate.WeekDay = RTC_WEEKDAY_SATURDAY;
  sDate.Month = RTC_MONTH_MAY;
  sDate.Date = 25;
  sDate.Year = 19;

  if (HAL_RTC_SetDate(&hrtc, &sDate, RTC_FORMAT_BIN) != HAL_OK)
  {
    Error_Handler();
  }
  /** Enable the WakeUp 
  */
  if (HAL_RTCEx_SetWakeUpTimer_IT(&hrtc, 5, RTC_WAKEUPCLOCK_CK_SPRE_16BITS) != HAL_OK)
  {
    Error_Handler();
  }
  /* USER CODE BEGIN RTC_Init 2 */

  /* USER CODE END RTC_Init 2 */

}

Serial output is:

10,,,15...0
10,,,15...0
10,,,15...0
10,,,15...0
10,,,15...0
10,,,15...0
10,,,15...0
10,,,15...0
10,,,15...0
10,,,15...0
10,,,15...0
.
.
.

PS.
RTC WakeUp is working as expected so the RTC is counting but I guess it is not storing counts in registers.

Best Answer

The solution is to call both GetTime and GetDate at the same time, If you call only GetTime it does not update correctly:

HAL_RTC_GetTime(&hrtc, &currTime, RTC_FORMAT_BIN);
HAL_RTC_GetDate(&hrtc, &currDate, RTC_FORMAT_BIN);

I don't know how they are connected, even more so because GetDate() is run after GetTime() and it still makes difference.

Related Solutions

Electronic – STM32 DMA Transfer bridge between 2 uart ports

Consider the following snippet from the STM32F1 manual regarding the USART data register and its corresponding status bit 'TXE':

Single byte communication

The TXE bit is always cleared by a write to the data register. The TXE bit is set by hardware and it indicates:

• The data has been moved from TDR to the shift register and the data transmission has started.

• The TDR register is empty.

• The next data can be written in the USART_DR register without overwriting the previous data.

This flag generates an interrupt if the TXEIE bit is set.

Can you imagine a scenario where you are writing into the data register before the previous byte has made it into the shift register? Think about the sequence of events when you receive a stream of bytes, especially when you receive the third or fourth byte, what is your transmitter doing at this point? Is its data register occupied?

As a previous comment mentioned, you likely need a way to buffer previous byte(s) if the TXE status bit is not set. Writing into the USART data register while the TXE status bit is not set is a guaranteed way to lose information.

Edit in response to comment:

That's one way to do it, I would imagine it would work. However, I think doing away with DMA and using the USART interrupts would be a better approach. You can have 2 interrupt service routines for when a byte is received and when the transmit data register is empty. Based on those two events, you can decide to buffer the data (in the RX handler) and to empty the buffer (in TX complete handler). Care must be taken in deciding when to enable/disable the TX complete interrupt. I think the overhead of setting up DMA makes more sense for larger sequential transactions into (or out of) buffers, and less so for the single byte-by-byte case.

Electronic – STM32 HAL UART Transmit DMA problem

First of all I can't get the stm to transmit at baud rates higher then the standard 115200, according to the datasheets both the FT2232H and the STM32F7 should be capable of at least 12M baud.

The hardware supports speeds up to 27 Mbit (well, you haven't told your part number, I'm looking at the F756 datasheet), but according to stm32f7xx_hal_uart.h, HAL won't accept a speed above 9M

#define IS_UART_BAUDRATE(BAUDRATE) ((BAUDRATE) < 9000001)

Moreover, it depends on the system clock speed, in the default configuration, when you don't touch the Clock Configuration tab in STM32CubeMX, everything operates on the 16 MHz internal HSI clock. That means at most 1 Mbit while you are using UART_OVERSAMPLING_16, or twice that if you switch to UART_OVERSAMPLING_8 (but then you'd lose noise detection).

Second is that I can't call the sendUART() function multiple times in a row, why isn't the DMA Fifo used to store the stuff I want to send?

Although there is a 16 byte DMA FIFO, it's not accessible to the software. There is no way to just append some more data to an ongoing DMA transfer. HAL does nothing but starts a DMA transfer from the buffer address supplied by the caller.

You have to wait until the transfer is finished, or suspend DMA, and still wait until the FIFO is empty. You can of course allocate a buffer yourself, add data as it comes, and restart DMA whenever it finishes and there is new data in the buffer.

Also whats the right way to echo back all received data but make use of the fifo so no data is lost when it's not polled in time?

It looks like to me, that you can't have both DMA and interrupts on every received character. At least, the ISR status register value would be useless, and the interrupt handler won't be able to decide what to do. Reading it could even interfere with the DMA transfer. Therefore, you must choose one.

Using DMA to put the data in a buffer (or two), you can then poll the transfer counter regularly in the idle loop or a timer interrupt. There won't be an immediate response, but it'd perhaps not matter at all, because the USB interface would incur some delay too.

Best Answer

Related Solutions

Electronic – STM32 DMA Transfer bridge between 2 uart ports

Electronic – STM32 HAL UART Transmit DMA problem

Related Topic