[En-Nut-Discussion] Courious problem with NutEventWait()

[Ulrich Prinz]

Hi Ole!

I did some traces but I didn't check the exeption bits in depth. But had
to finish the sensor quite fast. As the sensor is a slower one and the
Cortex hasn't anything to so elsewhere, I switched to polling the GPIO line.

I keep having a closer eye on that problem and if it persists QS will
find it really soon. Funny thing is, that it only arises on one sensor
type. On dozens of other ones it never showed up. And all of them use
the same platform of software ( not only Nut/OS but even the same sensor
software) and they use the same interfaces. The only difference was that
I tried to use external interrupt and waking up the thread via a handle.
But as I said before, handles are working fine in may other places of
this and other sensors.

May be I add a check pattern for those two stacks the Cortex uses too.
May be one of these runs over the limit.

I will come back to that in a few days after I finished the bootloader.

And may thanks for that link to the FAQ. This might be a good hint. I
have to check what addresses the gcc 4.6.0 inserts there and if it is
different to other / older versions of gcc.

Ulrich

Am 05.04.2011 17:33, schrieb Ole Reinhardt:
> Hi Ulrich,
> 
> indeed a quite strange problem. But google gave some interesting hints:
> 
> http://infocenter.arm.com/help/topic/com.arm.doc.faqs/ka12545.html
> 
> It might be a problem in the implementation of the scheduler as bit0 of
> the target address always have to be set to one on a branch on the CM3
> architecture (if I understood the above article correcly).
> 
> Might there be some special cases where your scheduler may fail?
> 
> 
> Can you track down the exception to a single instruction? AFAIK you
> should be able to read out the pc value of the place where the
> instruction occured (sorry, I just does not have by hand where this
> value is stored on a CM3, in the LR register?)
> 
> Also other error sources might be possible:
> 
> "Usage Fault: detects execution of undefined instructions, unaligned
> memory access for load/store multiple. When enabled, divide-by-zero and
> other unaligned memory accesses are also detected.
> 
> Bye,
> 
> Ole
>