ChibiOS Free Embedded RTOS

Problems look coupled, but I can create dedicated thread.

Previously you posted that the problems happen even before I2C is initialized so I assumed problems were unrelated.

I need a simple test application to try to reproduce the problem or there is not much I can do. Testing compiler options on the various F4 discovery demos yielded no results, all demos worked, it must be something specific of your setup.

Giovanni

I think the problems are related.

My code was definitely crashing when I tried to receive only one byte.
When I changed to reading more bytes, the crashes stopped.

If you are getting crashes when trying to receive one byte, try using a
larger receive buffer - say 4 bytes - and leave the receive count at 1.

When I did this, I no longer got crashes.

Craig

Hi Giovanny.
I have some new interesting bug:
http://rghost.net/41071059

My application use dedicated threads for each I2C device. All that threads
have same priority (NORMAL+5) except thread polling ITG3200 gyroscope,
it has priority NORMAL+7 (named PollGyro). Semaphores used for mutual
exclusion in drivers (I am not use mutexes at all).

All I2C threads synchronized with interrupts from I2C sensors using semaphores
signaled from EXTI ISRs. As you can see on screenshot "sp->s_queue" points
to 0x20009690, this is PollGyro thread. That error happens after 1-10 minutes
after program start. If I set priority of PollGyro thread same as other I2C threads
than my program able to run successfully whole night.

I think problem somewhere in priority handling inside chibios but I not familiar with it.

Hi,

This kind of random crashes are often caused by a race condition, not necessarily into the kernel. Apparently the semaphore gets corrupted, are you running with the state checker enabled?

Giovanni

Wait a moment,

Exactly why you think there is a problem with that state? is the assertion triggered?

Looking at the variable the semaphore state looks correct, the counter is -1 and there is a single thread in the list. The assertion should not be triggered.

Giovanni

I always have assertion enabled and it was triggered.

Very strange, are you sure you don't have stack overflows or other kind of overflows?

Giovanni

No stack overflows catches by assertions but after whole weekend debugging I am not sure at all.

That assertion can only be triggered if the fields p_prev and p_next of the thread pointer by the semaphore do not point back to the semaphore.

Anyway, try posting the code, all the places where you touch that semaphore.

Giovanni