cancel
Showing results for 
Search instead for 
Did you mean: 

HAL_Delay() gets stuck when working with MCSDK V6.2.0

mimho
Associate III

Hello everyone!

I finally managed to drive the motor using MCSDK V6.2 and our custom board using Board Manager!

But I faced a problem that never happened in MCSDK V5.4.8.

If I don't use HAL_Delay() function, the firmware successfully drives the motor and no problem is seen.

But If I use this function before running the motor, the firmware gets stuck( it seems like that  HAL_Delay()  is an infinite loop)

I suppose that something is wrong with systick interrupt.

the versions I used as follows:

cubeMX: V6.10

MCSDK: V6.2

Why this happens? Do you have any idea on how to solve it?

Your help is appreciated.

Regards

1 ACCEPTED SOLUTION

Accepted Solutions
mimho
Associate III

@GMA 

I made a test with cubeIDE V1.14.1 and the problem solved!

Apparently, something was wrong with the compiler! 

thanks for your time and effort,

Regards.

View solution in original post

9 REPLIES 9
GMA
ST Employee

Hello,
Could you please check that in your compile definitions, "MC_HAL_IS_USED" is defined?
HAL_IncTick() function must be called in SysTick_Handler() function.

If you agree with the answer, please accept it by clicking on 'Accept as solution'.
Best regards.
GMA
mimho
Associate III

Hello @GMA !

Thanks for your reply,

Yes, I checked it and it had been defined.( pls. see mc_hal_is_used.png)

Please refer to a screenshot I have attached  (delay.png). What I realized through debugging is that HAL_GetTick()  is running because uwTick is increasing. HAL_Delay() function is successfully called out for the very first time(based on waait1 and waait2 variables)

But here is the problem, it seems like the while loop never runs!((HAL_GetTick() - tickstart) isn't calculated

So, the firmware doesn't exit the loop and gets stuck forever.

delay.PNGmc_hal_is_used.png

I have also checked the priority of the systick interrupt and everything looks fine(I guess it is also confirmed by uwTick increasing)

I really don't know what causes this problem to arise and have never had the same problem so far.

if you could help me, I'd be so much grateful.

Regards.

mimho
Associate III

UPDATE: I need to mention that if I disable the motor control protocol (e.g. the over USART A button) and generate the project without the USART interrupt being generated, HAL_Delay() works fine.

Apparently, something is wrong with the USART interrupt. As I said, I changed the priority of the systick interrupt from 3 to 2 even 1 to give it a higher priority compared to the USART interrupt, but it didn't help.

when using the MCSDK V5.4.8, We have no problem with this situation. I suppose something related to the USART interrupt has been changed in the MCSDK V6.2.1 causing this problem.

Do you have any idea that might help?

Thanks!

GMA
ST Employee

Hello,

On which platform are you facing this issue? 
Could you attach the generated ioc please?

If you agree with the answer, please accept it by clicking on 'Accept as solution'.
Best regards.
GMA
mimho
Associate III

I am using cubeMX v6.10 and MDK ARM V5 as my IDE.

the generated ioc has been attached

Best regards.

GMA
ST Employee

Hello,

Made a test with a NUCLEO-F030R8, cubeMX v6.10 and CubeIDE v1.14.
I disabled the ASYNC on MCP settings, set Baudrate to 19200Bd/s and I did not face the same behavior calling HAL_delay() from main().
On my side, Systick priority is set to 3 instead of 2.

Could you check at infinite loop point the call stack? Are you under another interrupt?
May be, you also check the disassembly code? 

If you agree with the answer, please accept it by clicking on 'Accept as solution'.
Best regards.
GMA
mimho
Associate III

Hello @GMAGMA, really appreciate you!

I have attached the screenshots related to what you asked me.

It seems the firmware is completely stuck and is not under any interrupt (correct me if I'm wrong please)

as I said, disabling the MCP would completely solve the issue, but I'd rather use it.

if you need anything else, I'm ready to do anything you think that might help.

thanks a lot!

CALL_STACK_2.png

CALL_STACK.png

  

mimho
Associate III

I need to mention that whenever I try to connect to the board I get the firmware error,

mimho_0-1709448410730.png

 

mimho
Associate III

@GMA 

I made a test with cubeIDE V1.14.1 and the problem solved!

Apparently, something was wrong with the compiler! 

thanks for your time and effort,

Regards.