stStopAlarm?

[steved]

I'm running Chibi 3 on a 32F4, and every so often my code halts with a 'stStopAlarm' reason, or occasionally a 'stStartAlarm'.

Looks like I'm running in tickless mode. All debug options are turned on.

I can see that its related to the system timer being stopped and started, presumably as timers are stopped and started in the code. Are these problems likely to be due to timer-related calls from an incorrect context? Or some other reason?

[Giovanni]

That should not be happening, could you put together a small project that I can try?

Do you use virtual timers a lot in your application?

Giovanni

[steved]

That should not be happening, could you put together a small project that I can try?

Not sure how easy that's going to be! There's a certain amount going on:
- uGfx updating screens and bits of screens
- one I2C bus operating fairly continuously in slave mode (but at only 100kHz) - lots of DMA/interrupt/timer action there
- only three threads
- a 1ms timer tick (maybe I should just disable tickless mode!)

Now I know those errors shouldn't be happening, I'll have a closer look at what triggers them. Certainly from memory they are occurring when virtual timers are being adjusted.


Incidentally, I'm using ChibiStudio_Preview7, and when I try and use the ChibiOS/RT 3.xx plugin, it says 'ChibiOS/RT registry not enabled in kernel'. I have:
#define CH_CFG_USE_REGISTRY TRUE

in chconf.h - is anything else needed?

[Giovanni]

Hi,

What time resolution do you have in chconf.h? could you try increasing that "delta" parameter? normally it is set to 2, try 5 or more.

Giovanni

[steved]

I've run some tests with delta values of 2, 5 and 10, and on 10 runs of each it doesn't appear to make any difference. Subjectively the average time to crash is longer with a value of 10. Crash time is anything from a minute or two to more than 10 minutes.

I've also run a test with delta=0, and so far the unit has kept running for over 2 hours.

I've attached some stack traces taken with delta=10 which might give a clue.

[Giovanni]

The I2C driver seems to be always involved somehow but it does not look the regular one, are critical zones respected in that part of code? is the I2C interrupt priority below the kernel level?

Giovanni

[steved]

The I2C driver seems to be always involved somehow but it does not look the regular one, are critical zones respected in that part of code? is the I2C interrupt priority below the kernel level?

Giovanni

I noticed that, as well. In fact two of the attachments (relating to stop alarms) went missing - the I2C driver isn't involved in those.

The I2C driver is the one which supports slave and multimaster mode, originally written by brentr and moved over to 3.x. I've attached it again to save you looking for it. IRQ priority is set to 5.

I've got all the debugging options turned on in chconf.h; that would presumably catch problems with the critical zone?

STM32_ST_IRQ_PRIORITY is set to 8.
(In general everything is at the values set as defaults or in demos, unless there was a specific reason to change it)

[Giovanni]

I am trying the IRQ_STORM test application and that error is never triggered. Maybe I need to write a stress test specific for virtual timers but I donìt know exactly how to write it.

Apparently in your application the system tries to activate the ST timer comparator when it is already started or disable it when it is already disabled. This should not happen unless there is a kernel preemption into a critical zone.

I would check the priorities of all interrupts in your application.

Giovanni

[Giovanni]

Could you try removing this line from line 97 of st.c?

osalDbgAssert(stIsAlarmActive() != false, "not active");

This is probably an error because it can happen that the kernel tries to stop the comparator when it is already stopped. I can't explain the other error, I am still investigating that.

Giovanni

[steved]

Will do as soon as I can - managed to totally break things ATM....

Did find a possible absence of lock/unlock round the use of one of the timers in the i2c routines - not certain yet.