fix(LPBAM): initialize Request in LPBAM_LPTIM_FillStructInfo

[94xhn]

Resubmission of #73, closed because the CLA wasn't signed yet at the time — signed now.

Fixes #65.

Root cause

For the LPBAM_LPTIM_CONFIG_ID node, LPBAM_LPTIM_FillStructInfo() (Utilities/lpbam/STM32U5/stm32_ll_lpbam.c) only sets pDescInfo->Request in two cases:

• Config.State == ENABLE → DMA_REQUEST_SW
• Config.State != ENABLE and Config.Mode == LPBAM_LPTIM_UE_MODE → LPDMA1_REQUEST_LPTIM1_UE / LPDMA1_REQUEST_LPTIM3_UE

The remaining combination — Config.State != ENABLE and Config.Mode == LPBAM_LPTIM_NO_UE_MODE — falls through without ever assigning pDescInfo->Request.

The caller, LPBAM_LPTIM_FillNodeConfig() (Utilities/lpbam/stm32_lpbam_lptim.c), declares its LPBAM_InfoDesc_t desc_info; on the stack without initializing it, so in this case pDMANodeConfig->Init.Request ends up with whatever garbage happened to be on the stack. That value also decides pDMANodeConfig->Init.Direction (set to DMA_MEMORY_TO_PERIPH whenever Request != DMA_REQUEST_SW), so two otherwise-identical LPTIM "stop" nodes built the same way can end up with different DMA node configurations purely depending on unrelated stack contents at the time — this is exactly what @elektrojupp's report shows: two stop nodes built with the same code, one working and one not, traced down to differing Request bits in the resulting descriptors.

Fix

Set Request = DMA_REQUEST_SW for the missing case, matching the same choice already made in the Config.State == ENABLE branch just above it — both are cases where there's no specific hardware DMA request line tied to the transfer, so software-triggered is the consistent choice.

Testing

I don't have the affected hardware or STM32CubeMX/IDE set up to build the full LPBAM example project, so I can't provide a board-level test. What I did instead: extracted the exact branch structure of LPBAM_LPTIM_FillStructInfo()'s LPBAM_LPTIM_CONFIG_ID case into a standalone host-C reproduction (stand-in enums for the STM32U5-specific constants), compiled and ran with plain gcc:

• Before fix: State=DISABLE, Mode=NO_UE_MODE leaves Request as an uninitialized sentinel value.
• After fix: same input produces Request = DMA_REQUEST_SW (0), consistently.

This matches @elektrojupp's own account that "the suggested fix at least worked in my case. Both stop nodes working and no difference in descriptors."

Generative AI

I used generative AI tools when creating this PR, but a human has checked the code and is responsible for the code and the description above.

[MKISTM]

Hello @94xhn,

Thank you for this report. This point is already being tracked internally. I will keep you informed about our decision.

Best Regards,
KIWA Mohamed Chaker.