[Bug]: pointer misuse

[elektrojupp]

Bug Summary

Some weird use of pointers that requires two generated variables to be in a contiguous memory space which they are not guaranteed

Detailed Description

With reference to the LPBAM_SPI_TransmitReceive example for NUCLEO-U575ZI-Q in STM32Cube_FW_U5_V1.9.0:

main.c [43,44]

DMA_HandleTypeDef handle_LPDMA1_Channel0;
DMA_HandleTypeDef handle_LPDMA1_Channel1;

main.c [51]

DMA_HandleTypeDef *LPBAM_TxRx_MultiConf_DMAHandlers[2];

main.c [147,148]

LPBAM_TxRx_MultiConf_DMAHandlers[0U] = &handle_LPDMA1_Channel0;
LPBAM_TxRx_MultiConf_DMAHandlers[1U] = &handle_LPDMA1_Channel1;

main.c [166,175]

MX_TxRx_MultiConf_Start(LPBAM_TxRx_MultiConf_DMAHandlers[0U]);

/* Enter Stop2 mode */
Enter_Stop2_Mode();

/* LPBAM TxRx application MultiConf scenario stop */
MX_TxRx_MultiConf_Stop(LPBAM_TxRx_MultiConf_DMAHandlers[0U]);

/* LPBAM TxRx application MultiConf scenario unlink */
MX_TxRx_MultiConf_UnLink(LPBAM_TxRx_MultiConf_DMAHandlers[0U]);

Reference for pointer use:

lpbam_txrx_multiconf_config.c [199-211]

void MX_TxRx_MultiConf_Start(DMA_HandleTypeDef *hdma)
{
    /* LPBAM start DMA channel in linked-list mode */
    if (HAL_DMAEx_List_Start(&hdma[COUPLED_TRANSMIT_Q_IDX]) != HAL_OK)
    {
        Error_Handler();
    }

    /* LPBAM start DMA channel in linked-list mode */
    if (HAL_DMAEx_List_Start(&hdma[TRANSMIT_Q_IDX]) != HAL_OK)
    {
        Error_Handler();
    }
}

This clearly only works under the assumption that

DMA_HandleTypeDef handle_LPDMA1_Channel0;
DMA_HandleTypeDef handle_LPDMA1_Channel1;

are in this order directly one after the other in memory. The assumption does not hold and can create problems, especially when optimization is used.

The occurrence is forced by the function prototype, which is meant to be always

void MX_TxRx_MultiConf_Start(DMA_HandleTypeDef *hdma)

though it should be

void MX_TxRx_MultiConf_Start(DMA_HandleTypeDef **hdma)

and requires changing the function calls of both:

HAL_DMAEx_List_Start()

I assume that there is no "easy" workaround since it would require lots of changes in the code generator.

It is possible to fix this in the linker script theoretically, but a heck of work certainly not meant to work like this.

Though I am certain about this, please correct me if I am wrong.

Expected Behavior

reference the correct handle in function HAL_DMAEx_List_Start()

Actual Behavior

called the wrong handle when using optimization

Environment

LPBAM_SPI_TransmitReceive example for NUCLEO-U575ZI-Q in STM32Cube_FW_U5_V1.9.0 as an example but targets alle coupled queue lpbam generated code

Severity

Normal

[MKISTM]

Hello @elektrojupp,

Did you find any functional error or unexpected behavior due to this reported issue, or is it just an enhancement proposal?

Best Regards,
KIWA Mohamed Chaker.

[elektrojupp]

I copied the structure into an own project to find out, that it did work with -O0 but not work with -OS or -O3.
Then reviewd the code to see, that it works under the assumption that variables declared in c code one line after the other will most propably end up in a contiguous memory space. But the point is that this is not guaranteed. Before writing the issue i confirmed that both variables are not where they supposed to be.
So it kind of works, its even not forbidden, and i can understand that you dont want to change your function prototypes as they are used everywhere like this.
But since it makes the code working dependent on a (from my point of view) random compiler descision I consider it a bug rather than a proposal for a different coding style.

Best Regards,
Joseph

[MKISTM]

Hello @elektrojupp,

Thank you for your report, it seems that point makes sense.
Would you mind trying another approach and letting me know the behavior that you noticed?

Instead of API breaking, try using:

DMA_HandleTypeDef handle_LPDMA1_Channel[2];

rather than:

DMA_HandleTypeDef handle_LPDMA1_Channel0;
DMA_HandleTypeDef handle_LPDMA1_Channel1;

I believe that will ensure that the parameters are contiguous.

Best Regards,
KIWA Mohamed Chaker.

[elektrojupp]

This would certainly fix the issue, but but is in conflict with cubemx generated lpdma init function at.

main.c [360,411]

static void MX_LPDMA1_Init(void)
{
  .
  .
  .
    handle_LPDMA1_Channel0.Instance = LPDMA1_Channel0;
    handle_LPDMA1_Channel0.InitLinkedList.Priority = DMA_LOW_PRIORITY_LOW_WEIGHT;
    handle_LPDMA1_Channel0.InitLinkedList.LinkStepMode = DMA_LSM_FULL_EXECUTION;
  .
  .
  .
}