stStopAlarm?

[Giovanni]

That could explain the other problem, please let me know.

Giovanni

[steved]

Looks like the problem was a missing critical section round a VT operation in the i2c slave driver - it was causing both stop and start alarms. (From somewhere I had got the idea that, with all debug options on, this kind of error was caught. Obviously not).

I subsequently commented out the line in st.c which you suggested, with (unsurprisingly) no difference.

In the course of doing this, I noticed that the i2c driver still used chSysLock()/Unlock, so changed them all to osalSysLock()/Unlock. This was what resulted in a broken system - it caused the I2C driver to first malfunction, and then to crash - but on the master side (I have a slave I2C port running pretty continuously, and a master port being used occasionally). Looking at the files there 'should' have been no change in the underlying code, since osalSysLock() is an inline function, which just calls chSysUnlock() (which is itself an inline function). Hence the change of behaviour is somewhat surprising. Has anyone else seen anything like this?

[Giovanni]

That should not happen, osal functions are equivalent to ch functions and it works in all other drivers.

About the missing critical section, the state checker would have caught that, is it disabled in your setup?

Giovanni

[steved]

Definitely have:

#define CH_DBG_SYSTEM_STATE_CHECK TRUE

in chconf.h

(And other state checking bits have been working).

The missing critical section was around a chVTSetI()


I'll have to investigate the osal-related thing further - does seem very strange.

I do sometimes wonder if I have something slightly corrupted in my installation. I'm using Chibistudio 7, and the Chibi RT3 plugin says it can't find the registry when I try to view thread information. That's definitely enabled in chconf.h as well

[Giovanni]

The plugin is broken because the kernel changed, I have to update it in next ChibiStudio.

Giovanni