Modify of HAL library?

[Jang Wonyong]

Posted on April 09, 2018 at 08:33

HI,

I use SPI of HAL Library in STM32F0.

However, due to unaligned memory access, HardFault occurs in the HAL_SPI_TransmitReceive () function.So I modified the HAL library as follows.

uint8_t data_lo, data_hi;

uint16_t data16;

//hspi->Instance->DR = *((uint16_t*)hspi->pTxBuffPtr); <-original

data_lo = *hspi->pTxBuffPtr;

data_hi = *(hspi->pTxBuffPtr + 1);data16 = (uint16_t)data_lo | ((uint16_t)data_hi << 8); hspi->Instance->DR = data16;

//*((uint16_t*)hspi->pRxBuffPtr) = hspi->Instance->DR; 

<-

original

data16 = hspi->Instance->DR;

*hspi->pRxBuffPtr = (uint8_t)data16; *(hspi->pRxBuffPtr + 1) = (uint8_t)(data16 >> 8);

However, if the HAL library is updated, it needs to be modified again. How can I use it without modification?

Translated into Google Translator.

[Tesla DeLorean]

Posted on April 09, 2018 at 23:02

Then you have people who have kittens because the compiler throws warnings. The response should be to check the code in question for validity, not throw all the tea in the harbour.

In the CRC or SPI data register case there is specific need to control the width of the read/write, taking a 16-bit or 32-bit entity and accessing it with SMALLER granularity than the underlying item. In the case of the 8-bit pointer it is being casted to something with BIGGER granularity.

[waclawek.jan]

Posted on April 10, 2018 at 07:26

You should modify the source code in the Cube's repository location, as this file is copied during the generation of every project.

I don't use thus understand CubeMX's workings, but IMO this does not solve the OP's problem:

However, if the HAL library is updated, it needs to be modified again.

 JW

[Jang Wonyong]

Posted on April 10, 2018 at 07:45

If the transmission size is greater than 1 in 8 bit data mode, the HAL_SPI_TransmitReceive function performs the following routine.

hspi-> Instance-> DR = * ((uint16_t *) hspi-> pTxBuffPtr);

*((uint16_t*)hspi->pRxBuffPtr) = hspi->Instance->DR;

[Doug Kehn]

Posted on April 10, 2018 at 15:07

I happen to Cube ... what I do is place all code, including CubeMX generated code, in a Git repository. Git allows me to see the differences CubeMX made to the code after regenerating (due to modifying the project file and/or updating CubeMX or firmware library.)

I use markers to denote modifications to CubeMX generated code. I even do this for code inside USER CODE sections, just to be safe. The markers make it easier to identify (and remember) modifications I've made to CubeMX generated code. After regenerating, Git will show that my modifications to CubeMX generated code have been removed. In most instances, the CubeMX modifications (i.e. removal of my modifications) can be ignored; however, it's possible that CubeMX modifications need to be retained along with my modifications so a manual merge is needed. (I've even had the case where my modification is no longer needed after regenerating from a firmware library update.)

The markers I use are:

&sharpif 0 /* some_string */

     original code&sharpelse     modified code&sharpendif /* some_string */

or

&sharpif 1 /*some_string */

     added code&sharpendif /* some_string */

I'm sure there are other ways, probably even better, to do this. This works for me; maybe it'll be helpful to others.