Writing to peripheral registers directly, is it possible to do under HAL?

[Christopher Pappas]

Posted on August 25, 2016 at 15:59

I am guessing that the HAL lock and unlock mechanism prevents this from happening.

Does anybody have any ideas or suggestions to make simple writes to peripheral registers work again like they did in SPL? (example - GPIOA->ODR = 1;)

#synth-usb-midi-nucleo-144 #synthesizer-nucleo-144-f7 #hal-direct-write-peripheral-regs

[Tesla DeLorean]

Posted on August 25, 2016 at 16:58

No, I think it works just the same as before

    /* Enable the TSVREFE channel*/

    ADC->CCR |= ADC_CCR_TSVREFE;

..

    /* Clear the old SQx bits for the selected rank */

    hadc->Instance->SQR1 &= ~ADC_SQR1_RK(ADC_SQR1_SQ13, sConfig->Rank);

..

/**

  * @brief  Clears the EXTI's line pending flags.

  * @param  __EXTI_LINE__: specifies the EXTI lines flags to clear.

  *         This parameter can be any combination of GPIO_PIN_x where x can be (0..15)

  * @retval None

  */

#define __HAL_GPIO_EXTI_CLEAR_FLAG(__EXTI_LINE__) (EXTI->PR = (__EXTI_LINE__))

..

Software interlocks trying to serialize access don't change the hardware or bus interfaces.

[Walid FTITI_O]

Posted on August 25, 2016 at 18:09

Hi pappas.chris,

Yes, you can program with direct access register safely. Take into consideration, that there is a low level (LL) APIs with a little abstraction and high portability and simplicity is under developpment for all STM32s ( already released for some STM32 familie like the case of STM32L4, STM32L1). These LL APIs facilitates the coding and configurations' update under Hal projects.

-Hannibal-

[Christopher Pappas]

Posted on August 25, 2016 at 20:21

I gave it a try, It seems to be working as expected, but now I see that certain peripherals with buffered registers (ie. - TIM1->ARR) can get overloaded if the register is updated too quickly.

I just read this 

http://www.st.com/content/ccc/resource/sales_and_marketing/presentation/product_presentation/37/55/ff/bc/a8/71/4f/c5/stm32_embedded_software_offering.pdf/files/stm32_embedded_software_offering.pdf/jcr:content/translations/en.stm32_embedded_software_offering.pdf

 and noticed the timeline for STM32F7 Low-Layer delivery date is Q4 2016. I will wait for that time to come around. It seems as LL will solve many of the remaining issues I have with re-coding SPL to HAL. Thanks for the information, Hannibal & Clive !

[Walid FTITI_O]

Posted on August 26, 2016 at 13:52

Hi pappas.chris, 

For timer as example, there is a new application note ''General purpose Timers Cookbook''

http://www.st.com/content/ccc/resource/technical/document/application_note/group0/91/01/84/3f/7c/67/41/3f/DM00236305/files/DM00236305.pdf/jcr:content/translations/en.DM00236305.pdf

which is associated with firmware examples' package where the projects are done with a mix between Hal functions and direct access register's coding. Take a look to that :

http://www.st.com/content/st_com/en/products/embedded-software/mcus-embedded-software/stm32-embedded-software/stm32cube-expansion-software/x-cube-timcooker.html

-Hannibal-

[Christopher Pappas]

Posted on August 26, 2016 at 19:20

Thanks Hannibal once again!

The Timer Cookbook reminded me that the TIMx->ARR register is not truly buffered until the Auto-Reload-Preload (TIMx->CR1.ARPE) is enabled. That stopped the overload condition I was experiencing, and now I am getting no glitches with the timer outputs.

Thanks again Hannibal and all !!

Christopher