It’s an important information that the scheduler isn’t started yet when this problem happens. See e.g. this post Using Mutex before scheduler starts - #2 by rtel describing that interrupts might get disabled when calling FreeRTOS API before it’s running.
So if the I2C driver makes use of interrupts (I think it does) and the interrupt priority is in the range (logically) covered by configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY it won’t work.
It’s not a configuration issue. The problem is a side effect using FreeRTOS before it’s started.
You could implement an alternative ‘early boot’ version of the EEPROM read function without using the mutex or can you move the call into a (main) task running after the scheduler has started.
I’m using the second approach to do some task preparations right before entering the task (forever) loop.
1 Like