Strange crashes on MQX

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Strange crashes on MQX

Jump to solution
4,530 Views
dirkdoerr
Contributor III

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

Labels (4)
Tags (1)
1 Solution
3,107 Views
dirkdoerr
Contributor III

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.

View solution in original post

0 Kudos
13 Replies
3,108 Views
dirkdoerr
Contributor III

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.

0 Kudos
3,107 Views
rendy
NXP Employee
NXP Employee

Hi,

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

0 Kudos
3,107 Views
dirkdoerr
Contributor III

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

0 Kudos
3,107 Views
jackblather
Senior Contributor I

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

0 Kudos
3,107 Views
dirkdoerr
Contributor III

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.

0 Kudos
3,107 Views
rendy
NXP Employee
NXP Employee

Please send me the link to the elf file.

0 Kudos
3,107 Views
dirkdoerr
Contributor III

Did you get my link?

0 Kudos
3,110 Views
karina_valencia
NXP Apps Support
NXP Apps Support

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

0 Kudos
3,110 Views
juangutierrez
NXP Employee
NXP Employee

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.

0 Kudos
3,110 Views
dirkdoerr
Contributor III

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

3,110 Views
ngsari
Contributor II

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.

0 Kudos
3,110 Views
juangutierrez
NXP Employee
NXP Employee

Ok, Cool

Let us know how it goes

0 Kudos
3,110 Views
karina_valencia
NXP Apps Support
NXP Apps Support

rendy please continue with the  follow up.

0 Kudos