Strange crashes on MQX

[dirkdoerr]

Hello,

we are experiencing strange crashes when running our software on Vybrid MQX.

The same executable is causing an abort exception at different places i. e. different call stacks at different times (sometimes running for 2 minutes sometimes 10 minutes). We tried different AutoEVB boards with different CPU configurations. It makes no difference.

So the same .elf file is sometimes crashing after 2 minutes sometimes after 10 minutes with different call stacks although there it is a fully autonomous running demo with no external stimuli. Our software starts only one task.

The code page that seems to cause the crash is called several hundred times before. The same software is running on the same hardware on another RTOS without problems. The alleged code is the same on MQX and the other RTOS i. e. it is not  os dependent.

Could please someone at Freescale contact us directly for more details?

Kind regards

      Dirk

[dirkdoerr · Accepted solution]

Sorry for not updating this ticket.

Since we updated VG driver, MQX and GCC we have never seen that error again. All the tests that crashed before within 10 minutes are now running for hours without problems.

[rendy]

Hi,

could you please provide a code sample which demonstrates this issue?

[dirkdoerr]

No, it is not visible in a specific code sample. It happens at totally different code places. The whole code is about >= 500 files (not including the MQX BSP or the OpenVG driver stack). 

If you contact me directly I could send you a ftp link to download an elf file that shows the problem.

Regards

          Dirk

[jackblather]

What is the size of your MQX stack? You may have already checked this, but just in case....

[dirkdoerr]

The task is configured for 32 kB stack size. But it should use only a fraction of this. But I could double check.

An important information was missing in my original description. I have not seen it crashing in debug build only in release. And yes, I have checked initialisation of variables. And keep in mind that the same code is running on different hardware and OS configurations. Only a small part is platform dependent. The crashes does not occur in any platform dependent code part.

[rendy]

Please send me the link to the elf file.

[dirkdoerr]

Did you get my link?

[karina_valencia]

juangutierrez please continue with the  follow up due  Rene is not available.

[juangutierrez]

Could you post the compilation FLAGS for both the DEBUG and RELEASE mode, please?

If debug mode is ok, probably some optimization (included in release mode) might be causing the problem.

You can try changing the debug configuration by adding one by one the options until it resemble the release mode and see if after adding some flag, the issue shows up.

[dirkdoerr]

We are currently testing with the OpenVG 0.7.0 stack that Bill Kraker provided us.

In order to use this we changes

VG driver from 0.5.0 to 0.70

MQX from 4.0.2 Alpha 2 to 4.1.0

GCC from CodeSourcery 4.6 to GNUARM 4.7 (using hardfloat instead of softfloat ABI)

using the compile flags from your delivery.

With this setup and without any change in our code base I couldn't observe the reported problem anymore.

It is a bit early to say it is resolved and it would still be nice to know what fixed it but right now I have to catch up with our implementation.

Regards

    Dirk

[ngsari]

My Guess is that. Vybrid GFX Ram could be only accessed dword aligned. If any part of your code (stack, data, etc...) somehow access that area misaligned, that will cause a "weird" crash.

[juangutierrez]

Ok, Cool

Let us know how it goes

[karina_valencia]

rendy please continue with the  follow up.