Skip to main content
Visitor II
February 2, 2018
Question

MotionPM seems to crash after 4 iterations

  • February 2, 2018
  • 5 replies
  • 1353 views
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?

    This topic has been closed for replies.

    5 replies

    ST Employee
    February 2, 2018
    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?

    Visitor II
    August 21, 2018

    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

    ST Employee
    August 21, 2018

    The same recommendation, please try to increase stack size.

    What is your current stack size settings?

    Visitor II
    August 22, 2018

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

    Just it takes more time to crash.

    ST Employee
    August 22, 2018

    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.