cancel
Showing results for 
Search instead for 
Did you mean: 

Behaviour of PC13 not as expected.

John Fitter
Associate II
Posted on March 17, 2018 at 16:25

I am setting up a board that uses an STM32F103C8. It has an LED on PC13. I am running FreeRTOS and configuring with STMCubeMX. I am also enabling the LSE clock and RTC.

Using Cube MX I configure this and ensure that TAMPER is disabled/PC13 is GPIO and Output. I would therefore expect that PC13 (tamper pin) would behave as a GPIO and the LED would work. This is not the case.

The LED remains ON which means that PC13 is LOW. Nothing I do will change this. I have spent a great amount of time reading the documentation and studying the HAL, which I suppose is a good thing, but it has not solved my problem. I have also tried test code calling HAL and HALex functions but with no success. 

The chip documentation is vague about the behaviour of PC13 when the RTC is configured to use LSE. CubeMX is clear - it is a valid setting, but it does not work. I can find no place in the HAL where this pin may or may not be reconfigured.

Does anyone have any idea what is going on here? I have run out of time to fix this. I have papers to mark and a cranky supervisor to satisfy with a long report. I have hung an LED off another pin which solves the problem for now, but this is not a solution, just a kludge.

I really should bin my el-cheapo STM boards and stick with my Nucleos. At least they work as I expect.

5 REPLIES 5
Posted on March 18, 2018 at 09:53

I use this board as well without RTOS.

Simple project using HAL drivers should work out of the box. Configure only the PC13 as output. Use HAL function to toggle the PC No fancy configuration.

Start w/o RTOS to see if you have reproduce the issue to eliminate RTOS dependencies (if the task is called by the RTOS, etc). Start from elementary case w/o RTOS.

The problem arises when you use LL drivers instead as the CubeMX generated GPIO init is broken - see details here:

https://community.st.com/0D50X00009XkYowSAF

Posted on March 18, 2018 at 11:25

Read out and check the content of relevant GPIO and BKP registers (BKP_RTCCR.CCO and BKP_CR.TPE).

JW

John Fitter
Associate II
Posted on March 18, 2018 at 19:32

Thanks to everyone who answered this question. I have solved the problem with the help of this post 

https://community.st.com/0D50X00009XkW3eSAF

 .

This is not a true solution, but a workaround. The real problem is that CubeMX fails to generate the correct code. It should be fixed.

The workaround works but is applied 'after the fact'. Without the workaround PC13 is configured as a 'tamper' pin and it stays that way, through power cycles. The only way to fix it is to write 'one off' code that changes it back then be sure never to run code again without the workaround.

Muse
Associate

I have been struggling with the PC13 pin having a wong value because of the RTC. Unfortunately I was using PC13 as my ON/OFF button and it was causing my device to switch off everytime. Finally I have found the issue. The issue is in the HAL_RTC_SetTime() function of the HAL rtc library.

  /* Clear RTC_CR FMT, OSEL and POL Bits */
    hrtc->Instance->CR &= ((uint32_t)~(RTC_CR_FMT | RTC_CR_OSEL | RTC_CR_POL));
    /* Set RTC_CR register */
    hrtc->Instance->CR |= (uint32_t)(hrtc->Init.HourFormat | hrtc->Init.OutPut | hrtc->Init.OutPutPolarity);

As you can see in the code it is writing values on the Control registers of the RTC. As I was not setting those values in my code they were having a random value which is being transfered to the control registor.

Now I have fixed this issue by setting the hrtc->Instance->CR to the value I want it to be (enabling and disabling bits as per my RTC requirment). (Please refer to the RM0090 Reference manual Page818 RTC control Registers).

As I am only using the RTC for Date and time purpose I always set the hrtc->Instance->CR(RTC control register) have value 0x30 and make sure that it has this value everytime.

Hope this will help.:D

MAJID_AR
Associate

I've fixed this problem.

Commented the following line in the library (stm32f1xx_hal_rtc.c)

And power off the RTC block (VBAT - VDD - VDDA)

And then restart