Loading...
 

SW4STM32 and SW4Linux fully supports the STM32MP1 asymmetric multicore Cortex/A7+M4 MPUs

   With System Workbench for Linux, Embedded Linux on the STM32MP1 family of MPUs from ST was never as simple to build and maintain, even for newcomers in the Linux world. And, if you install System Workbench for Linux in System Workbench for STM32 you can seamlessly develop and debug asymmetric applications running partly on Linux, partly on the Cortex-M4.
You can get more information from the ac6-tools website and download (registration required) various documents highlighting:

System Workbench for STM32


false condition if statement getting executed inside ISR

India

I’m trying to code an STM32F303 on the STMEVAL-ESC001V1 board
I added the following ISR as user code in the code generated my STM32CubeMX on System Workbench for STM32.
-----------------------------------------
void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)
{
// Prevent unused argument(s) compilation warning
UNUSED(GPIO_Pin);
// NOTE: This function Should not be modified, when the callback is needed,
//the HAL_GPIO_EXTI_Callback could be implemented in the user file

PRX_PinState = HAL_GPIO_ReadPin(PRX_GPIO_Port,PRX_Pin);

if(PRX_PinState==GPIO_PIN_SET)
{
FInstance = GETVAL();
tON = FInstance - RInstance;
}
if(PRX_PinState==GPIO_PIN_RESET)
{
RInstance = GETVAL();
tOFF = RInstance - FInstance;

}
}


uint32_t GETVAL(void){
return __HAL_TIM_GET_COUNTER(&htim2);
}
-----------------------------------------

I intend to record the timer value during a rising edge and falling edge on the PRX Pin.
I’m probing the pin and I’m using STMStudio to monitor the global variables.
I’m able to verify the rise and fall reflected on PRX_PinState variable.
It is switching between 1 and 0 as expected.
Which means the If conditions must alternate between true and false.
But when the PRX_PinState switch between 1 and 0, both FInstance and RInstance are refreshed with new values( which are very close number) This means both the if statements are being entered into and executed.
I’m so puzzled i don’t know why.
I’ve tried moving the code and performing it outside the ISR. Everything works fine (not really)
Well, I’m pretty confident that there is problem in the “if” statement’s execution.
But I can’t imagine why.
I also tried using else. (was like that initially)
-----------------------------------------
if(PRX_PinState==GPIO_PIN_SET)
{
FInstance = GETVAL();
tON = FInstance - RInstance;
}
else
{
RInstance = GETVAL();
tOFF = RInstance - FInstance;

}
-----------------------------------------
FInstance = GETVAL(); and RInstance = GETVAL(); are executed immediately one after the other.
How ?
I cannot move further in my project without using a “condition” (to check whether rising or falling).
Please help me.

France

Hi,

Just a thought: what is driving the PRX pin? If you drive it from, say, a switch, then you probably get stuck by lacking a proper debouncing of the input (if you don’t understand the problem, just Google “debounce”...).

PRX is then going several times very fast on and off and, if you look at the variables you get the impression that both alternatives are executed at once while in fact there is two interrupts, one going the ON path and the next one going almost immediately to the OFF path then a third one going to the ON path again, finally ruining your time measurement effort...

HTH

Bernard (Ac6)


India

Hi,

Thanks for replying.

It is not a bouncing issue. I wouldn’t write here without verifying something as silly.
Also, if it was, it wouldn’t execute statement in both if and else parenthesis.
Once again, How in the world is it possible that both “IF” and “ELSE” condition be true to execute both sets simultaneously.
I am not using two interrupts, but one, that detects both rising and falling edges.
The edges are differentiated by GPIO Read. (PRX_PinState) which is the digital state of Pin PA15.
The variables I’m monitoring reflect the timer value. Looking at the values it’s very obvious that they are executed sequentially.

What can I do ? I wanted to run this project on another IDE (CubeIDE) and had funny errors when building(I’ve put them below). I’m stuck.

23:50:52 **** Incremental Build of configuration Debug for project BLDC_Home ****
make -j4 all
arm-none-eabi-gcc “../Src/main.c” -mcpu=cortex-m4 -std=gnu11 -g3 -DUSE_HAL_DRIVER -DSTM32F303xC -DARM_MATH_CM4 -DDEBUG -c -I../../Drivers/CMSIS/Include -I../../MCSDK_v5.4.3/MotorControl/MCSDK/MCLib/Any/Inc -I../../Drivers/STM32F3xx_HAL_Driver/Inc/Legacy -I../../Drivers/STM32F3xx_HAL_Driver/Inc -I../../Inc -I../../MCSDK_v5.4.3/MotorControl/MCSDK/MCLib/F3xx/Inc -I../../MCSDK_v5.4.3/MotorControl/MCSDK/UILibrary/Inc -I../../MCSDK_v5.4.3/MotorControl/MCSDK/SystemDriveParams -I../../Drivers/CMSIS/Device/ST/STM32F3xx/Include -O0 -ffunction-sections -fdata-sections -Wall -fstack-usage -MMD -MP -MF”Src/main.d” -MT”Src/main.o” --specs=nano.specs -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb -o “Src/main.o”
arm-none-eabi-gcc “../Src/mc_api.c” -mcpu=cortex-m4 -std=gnu11 -g3 -DUSE_HAL_DRIVER -DSTM32F303xC -DARM_MATH_CM4 -DDEBUG -c -I../../Drivers/CMSIS/Include -I../../MCSDK_v5.4.3/MotorControl/MCSDK/MCLib/Any/Inc -I../../Drivers/STM32F3xx_HAL_Driver/Inc/Legacy -I../../Drivers/STM32F3xx_HAL_Driver/Inc -I../../Inc -I../../MCSDK_v5.4.3/MotorControl/MCSDK/MCLib/F3xx/Inc -I../../MCSDK_v5.4.3/MotorControl/MCSDK/UILibrary/Inc -I../../MCSDK_v5.4.3/MotorControl/MCSDK/SystemDriveParams -I../../Drivers/CMSIS/Device/ST/STM32F3xx/Include -O0 -ffunction-sections -fdata-sections -Wall -fstack-usage -MMD -MP -MF”Src/mc_api.d” -MT”Src/mc_api.o” --specs=nano.specs -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb -o “Src/mc_api.o”
arm-none-eabi-gcc “../Src/mc_config.c” -mcpu=cortex-m4 -std=gnu11 -g3 -DUSE_HAL_DRIVER -DSTM32F303xC -DARM_MATH_CM4 -DDEBUG -c -I../../Drivers/CMSIS/Include -I../../MCSDK_v5.4.3/MotorControl/MCSDK/MCLib/Any/Inc -I../../Drivers/STM32F3xx_HAL_Driver/Inc/Legacy -I../../Drivers/STM32F3xx_HAL_Driver/Inc -I../../Inc -I../../MCSDK_v5.4.3/MotorControl/MCSDK/MCLib/F3xx/Inc -I../../MCSDK_v5.4.3/MotorControl/MCSDK/UILibrary/Inc -I../../MCSDK_v5.4.3/MotorControl/MCSDK/SystemDriveParams -I../../Drivers/CMSIS/Device/ST/STM32F3xx/Include -O0 -ffunction-sections -fdata-sections -Wall -fstack-usage -MMD -MP -MF”Src/mc_config.d” -MT”Src/mc_config.o” --specs=nano.specs -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb -o “Src/mc_config.o”
arm-none-eabi-gcc “../Src/mc_interface.c” -mcpu=cortex-m4 -std=gnu11 -g3 -DUSE_HAL_DRIVER -DSTM32F303xC -DARM_MATH_CM4 -DDEBUG -c -I../../Drivers/CMSIS/Include -I../../MCSDK_v5.4.3/MotorControl/MCSDK/MCLib/Any/Inc -I../../Drivers/STM32F3xx_HAL_Driver/Inc/Legacy -I../../Drivers/STM32F3xx_HAL_Driver/Inc -I../../Inc -I../../MCSDK_v5.4.3/MotorControl/MCSDK/MCLib/F3xx/Inc -I../../MCSDK_v5.4.3/MotorControl/MCSDK/UILibrary/Inc -I../../MCSDK_v5.4.3/MotorControl/MCSDK/SystemDriveParams -I../../Drivers/CMSIS/Device/ST/STM32F3xx/Include -O0 -ffunction-sections -fdata-sections -Wall -fstack-usage -MMD -MP -MF”Src/mc_interface.d” -MT”Src/mc_interface.o” --specs=nano.specs -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb -o “Src/mc_interface.o”
../Src/mc_interface.c:24:10: fatal error: mc_math.h: No such file or directory
#include “mc_math.h”

~~~~~~ compilation terminated. ../Src/mc_config.c”>19:10: fatal error: main.h: No such file or directory

#include “main.h”

~20:10: fatal error: mc_interface.h: No such file or directory

#include “mc_interface.h”

~~~~~~~<span style="color”> compilation terminated. make”> *** Src/subdir.mk:47: Src/mc_api.o Error 1

make: *** Waiting for unfinished jobs....
make: *** Src/subdir.mk:49: Src/mc_config.o Error 1
make: *** Src/subdir.mk:51: Src/mc_interface.o Error 1
../Src/main.c:22:10: fatal error: main.h: No such file or directory
#include “main.h”

~

compilation terminated.
make: *** Src/subdir.mk:45: Src/main.o Error 1
“make -j4 all” terminated with exit code 2. Build might be incomplete.

23:51:33 Build Failed. 9 errors, 0 warnings. (took 41s.388ms)


France

Sorry, but if you had a bouncing issue, you would have exactly what you describe:

  1. PRX goes from OFF to ON, generating interrupt that goes through the THEN part (setting Finstance to X
  2. PRX goes almost immediatly to OFF again (bouncing), generating the same interrupt that goes now through the ELSE part (setting Rinstance to X+x µs and tOFF to xµs where x should be quite small)
  3. the PRX goes again ON, sending again the same interrupt but going again through the THEN part, setting F instance to X + y µs, y slightly greater than x, and tON to y - x, again quite small)


Another option, that may or may not give the same result, is that your callback may be called twice, for two different GPIO pins; you should test the value of GPIO_pin and only execute your code if it is the expected pin; however, you should probably always go through teh same branch of the IF, so the problem could go unnoticed.

That’s the only reasonable possibility; there is no way the compiler can generate an IF/THEN/ELSE construct so that it executes BOTH the then and else parts. If it does, in such a simple case, it will never, ever, go past the simplest test and be distributed at more than 2 or 3 users...

As a rule of thumb, when something does not work as expected, the bug is in my code, never in the compiler (well, being honest, as I’m a compiler writer, it occurs to me a few times that the compiler was wrong, but it was MY code that was failing, not the compiler compiling it :-)).

SW4STM32 uses the linaro compiler just for that: the provided binary was extensively tested before being released so you can trust it: if your code behaves this way, it’s because you ask it to behave like that.

Bernard (Ac6)

India

I’m sorry Bernard, My bad.
You were right :-)
I added a counter to watch how many time the ISR was executed. I noticed that code was interrupted anywhere from 15 to 100 times every time the signal switched. What caused me to believe it wasn’t a bouncing issue was that the exact same code ran perfectly well on my STM32F411 but behaved funny on the F303 Motor Control Board (Obviously because of the speed of operation). I do have debouncing hardware and my scope however doesn’t show any noise at a fair scale. I believe I can’t do much to the hardware.
Is there a way I can control the Interrupt Handler ?
I would like prevent interruption for 1µs after a trigger detection.

France

The simplest way to go, as you measure time between the last interrupt, is to just ignore any interrupt occuring less than x µs after a previous interrupt. Thus the first switch will be taken into account, then all bounce IRQs will be ignored waiting for at least x µs without any interrupt.

If you have ONLY one GPIO generating interrupts on the port where you connect the EXTI interrupt, then you may disable this IRQ in the NVIC, arm a timer for x µs, then re-enable teh EXIT interrupt in the NVIC when the timer expires; that is a bit more complex, but will cost less CPU cycles...

Bernard (Ac6)