cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H7 HRTIM in capture mode with 2 events: is the HAL really this non intuitive and wasteful?

RMart.0
Associate III

One can use STMCubeMx to configure the hrtim in capture mode based on 2 events. In my case, I'm using TIMER_A capturing event 1 & 6 and timer_B capturing events 2 and 7.

I can see the generated code's MX_HRTIM_Init() configuring everything correctly, calling HAL_HRTIM_EventConfig() with correct parameters, setting both "fast mode" for events 1&2 and "filters" for events 6&7.

I can also see MX_HRTIM_Init() configuring the timers as per the selected events, by calling 2x for each timer HAL_HRTIM_WaveformCaptureConfig()

Yey, this is all great and as it should!

But then you need to use a function to get the data from the capture. Let's use the example of HAL_HRTIM_SimpleCaptureStart_DMA(): inside that function, the following takes place: 

hhrtim->Instance->sTimerxRegs[TimerIdx].CPT1xCR = hhrtim->TimerParam[TimerIdx].CaptureTrigger1;

This basically overrides the originally well configured events that was done in MX_HRTIM_Init(), replacing it with values of a temporary ram structure. Looking further in the HAL code, one can see that this structure will hold uninitialized values if one does not call first HAL_HRTIM_SimpleCaptureChannelConfig(), which basically loads this temporary RAM structure with the configuration to take place when the HAL_HRTIM_SimpleCaptureStart_DMA() is called.

And this is my question: am I misunderstanding something here or is the HAL really surprisingly structured so that:

1) MX_HRTIM_Init() configures everything all nice and dandy as per your wishes in STMCubeMx

2) One needs then to manually call HAL_HRTIM_SimpleCaptureChannelConfig() and pass to it all 4 sets of config once again, now manually coded and non STMCubeMx based, just so that a RAM structure holds the config.

3) HAL_HRTIM_SimpleCaptureStart_DMA() will then use this RAM config copy and overwrite the original proper STMCubeMx based config that was correctly done in MX_HRTIM_Init().

Why would the HAL need to hold this wasteful RAM structure with a copy of a config that was already applied at init()?

Can't 2) above be removed and have HAL_HRTIM_SimpleCaptureStart_DMA() not overwriting hhrtim->Instance->sTimerxRegs[TimerIdx].CPT1/2xCR since it has already been configured properly in the init()?

Note: Using STM32CubeH7 Firmware Package V1.7.0

1 ACCEPTED SOLUTION

Accepted Solutions
RMart.0
Associate III

ok, never mind, just found HAL_HRTIM_WaveformCountStart_DMA() which seems to be doing exactly as one would expect: start the DMA without re-configuring the events etc...

View solution in original post

1 REPLY 1
RMart.0
Associate III

ok, never mind, just found HAL_HRTIM_WaveformCountStart_DMA() which seems to be doing exactly as one would expect: start the DMA without re-configuring the events etc...