cancel
Showing results for 
Search instead for 
Did you mean: 

MotionPM seems to crash after 4 iterations

Norman S
Associate II
Posted on February 02, 2018 at 07:06

My setup is very similar to my setup in previous question: 

https://community.st.com/message/182613-re-motionar-initialize-function-gets-stuck?commentID=182613&et=watches.email.thread#comment-182613

 

SensorTile + DataLogger sample project + SDCard + MotionAR

Now I'm trying to add MotionPM to the mix. I'm able to call the init function and get the version number of the library. I then proceed to call the Update function in a loop. It seem like it takes an update only 4 times before we jump into an error handler.

I understand that this is not a lot to go by, but does this give anyone any clues as to what I may be missing?

5 REPLIES 5
Miroslav BATEK
ST Employee
Posted on February 02, 2018 at 08:38

I think it could be problem with small stack size. Could you please try to increase stack size?

SScla
Associate II

Hi Norman,

the same seems to happen in our project, but after more than 4 iterations and only if we move the device continously. 

The Keil Compile output shows 

"Call chain for Maximum Stack Depth": Sch_ExecRun ⇒ MotionPM_Update ⇒ runStepDetection ⇒ FilterData ⇒ __aeabi_drsub ⇒ __aeabi_dadd ⇒ _double_epilogue ⇒ _double_round

"Maximum Stack Usage" = 5792 bytes + Unknown (Cycles, Untraceable Function Pointers).

We have configured Heap Size to 0x1200 and StackSize to 0x2000, but the MotionPM is still crashing / generating many FPU Error Interrupts.

If you disable the FPU error, the system will crash for HardFault.

We're still looking for solutions. 

Could you let me know if you figure out a solution? 

Many Thanks and Regards,

Stefano

Miroslav BATEK
ST Employee

The same recommendation, please try to increase stack size.

What is your current stack size settings?

SScla
Associate II

Now we've tried with 0xA000 and the same problem happen.

Just it takes more time to crash.

Miroslav BATEK
ST Employee

It is difficult to advise, if I don't know your firmware. I'm not aware about any issue in the library.

In our examples we use stack size 0x8000 and the program runs without any issue on Nucleo boards.

Can you try to increase the stack even more, maybe your other part of the firmware also has big memory demand.