Unexpected behaviour of LL_EXTI_TRIGGER_NONE in LL_EXTI_Init

[frosticles]

The way LL_EXTI_Init is written in all of the cube APIs means if you do this:

 

 LL_EXTI_InitTypeDef exti_config = {
 .Line_0_31 = foo,
 .LineCommand = ENABLE,
 .Mode = LL_EXTI_MODE_IT,
 .Trigger = LL_EXTI_TRIGGER_NONE,
 };

 LL_EXTI_Init(&exti_config);

 

The LL_EXTI_Init function will take no action, but will return SUCCESS.

This is a problem if the EXTI trigger mode was previously set to something other than LL_EXTI_TRIGGER_NONE, because the EXTI trigger will left enabled, with no clear error.

Granted of course I can just change my code to set the LineCommand to DISABLE instead to remove the trigger, but it seems a bit counter-intuitive that LL_EXTI_TRIGGER_NONE doesn't clear the triggers.

It would be useful if LL_EXTI_TRIGGER_NONE was added to the case statement:

 case LL_EXTI_TRIGGER_RISING_FALLING:
 LL_EXTI_EnableRisingTrig_0_31(EXTI_InitStruct->Line_0_31);
 LL_EXTI_EnableFallingTrig_0_31(EXTI_InitStruct->Line_0_31);
 break;
 case LL_EXTI_TRIGGER_NONE:
 LL_EXTI_DisableRisingTrig_0_31(EXTI_InitStruct->Line_0_31);
 LL_EXTI_DisableFallingTrig_0_31(EXTI_InitStruct->Line_0_31);
 break;
 default:
 status |= 0x02u;
 break;

Or at the very least, just remove the surrounding if statement

 if (EXTI_InitStruct->Trigger != LL_EXTI_TRIGGER_NONE)
 {
 switch (EXTI_InitStruct->Trigger)
 ...
 default:
 status |= 0x02u;
 break;
 }

so that if the user provides LL_EXTI_TRIGGER_NONE, the default branch will be executed to generate an error.

Thanks

[SHs]

Hello @frosticles 

An internal ticket 179329 has been submitted to update the LL_EXTI_Init API to allow LL_EXTI_TRIGGER_NONE use case.

Thank you for highlighting to us this issue.

[SHs]

Hello @frosticles ,

the LL_EXTI_TRIGGER_NONE value is relative to the configuration of an EXTI direct line either in interrupt or event mode. This is why the LL_EXTI_Init() returns SUCCESS. The same applies for HAL and LL drivers.

since the EXTI lines are direct or configurable, we do not imagine an application usecase where the trigger is changed between LL_EXTI_TRIGGER_NONE to other values and vice versa. Taking this into consideration, we do not think of any driver change at this stage