Clutching at straws: guru doesn't like me in uxListRemove() (freertos/list.c: 218)

[ESP_Angus]

A possible answer (still testing): allow the idle task to run. If I put a vTaskDelay() of 100 ms after deleting my "LED" task then, so far at least, the problem does not occur. Is it possible that FreeRTOS is getting confused when the task is created once more after it has been deleted if FreeRTOS is not allowed to do some form of clean-up first?

Yes, calling vTaskDelete() stops the task from being scheduled to run again but doesn't free all the associated resources. The task's resources aren't fully released until after the FreeRTOS idle task has a chance to run and "clean up" the task. This is part of the FreeRTOS design.

As you're using static resources, if the vTaskStaticCreate() is run before the idle task has cleaned up, there's a high chance of a problem.

[ESP_Sprite]

Agreed. My guess would be that you delete your task, then immediately re-create it in the same memory. The task still is on the to-be-deleted list, so when finally the idle task kicks in, it thinks the newly-created task isn't running anymore and should be cleaned up and happily clobbers all the structures it's in.

[RobMeades]

Confirmed: with a vTaskDelay() of 100 ms after the task was deleted on an overnight run of 832 cycles there were no more occurrences of the panic. Just wish I hadn't spent 3 days trying to find a nasty memory-stomp in my code! I guess from a FreeRTOS point of view doing any checking to defend against this is just fat but it would be kinda nice, or maybe just a mention in the documentation.

Anyway. thanks for all your swift help guys, now sorted.