I have tried several differnet methods of creating a pxDisk object before the TaskScheduler is running. Is there a way to open an SD card using the HSMCI subsystem before the TaskScheduler. I have tried to use pxDisk = FFSDDiskInit( SDCARDDISKNAME ) but it hangs waiting for a timeout that never happens because the Scheduler is not running. Thanks

I am not sure if Semaphores ( queues ) and Event Groups can be created safely before the kernel has been started? Other API’s are not needed as long as the kernel does not run ( see here below ). Well, except for xEventGroupSetBits(). Can anyone comment on this please? As far as I know, the FreeRTOS+FAT library needs the FreeRTOS kernel only in a few places. Most importantly is the locking of the drive, of the FAT and of directory changes. Please have a look at ff_locking.c. Every FAT drive has a semaphore that protects against concurrent access to that drive from different tasks. Also, every driver ( every I/O manager ) has an Event-Group that keeps track of temporary locks on the FAT and directory changes. As long as the scheduler does not run, locking should not be necessary. I’m thinking out loud: you could insert a statement in most of the functions: ~~~ void FFPendSemaphore( void *pxSemaphore ) { + if( xTaskGetSchedulerState() != taskSCHEDULERRUNNING ) + { + return; + } configASSERT( pxSemaphore ); xSemaphoreTakeRecursive( ( SemaphoreHandlet ) pxSemaphore, portMAXDELAY ); } ~~~ And avoid using Event Groups: ~~~ void FFLockFAT( FFIOManagert *pxIOManager ) { + if( xTaskGetSchedulerState() != taskSCHEDULERRUNNING ) + { + return; + } … } ~~~ Another thing might be timeouts: if xTaskGetTickCount() is used to limit actions, it will not work properly. But that is of later care. I’m attaching a new version of ff_locking.c that you can try out.

As far as I know, ALL FreeRTOS object can be created before the scheduler is started. You can also give/take from semaphores/mutexes/queues etc, with the one limitation that these must be able to immediately return, i.e they can’t attempt to block.

ALL FreeRTOS object can be created before the scheduler is starte

Thanks. I thought so, but I wanted to make it sure. @Larry : I would close all file handles before starting the scheduler. Or you can even destroy the handle to the disk ( FF_SDDiskDelete( px_Disk ) ). If you still notice a hang after the changes, please try to figure out where it hangs. That would be helpful.

You might consider starting a minimal FreeRtos system with one task that completes all your SD card needs, then it start all other task as needed, then suspended itself… On Tue, Jan 1, 2019 at 11:31 PM Hein Tibosch wrote:

ALL FreeRTOS object can be created before the scheduler is starte Thanks. I thought so, but I wanted to make it sure. @Larry : I would close all file handles before starting the scheduler. Or you can even destroy the handle to the disk ( FFSDDiskDelete( pxDisk ) ). If you still notice a hang after the changes, please try to figure out

where it hangs. That would be helpful.

I need to open an SD card and read configuration data before the TaskScheduler is running

https://sourceforge.net/p/freertos/discussion/382005/thread/635b25cf8b/?limit=250#4de5

Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/freertos/discussion/382005/ To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

>

~~ _/) ~~~~ _/) ~~~~ _/) ~~~~ _/) ~~ Tom Lafleur

THinking a bit, while the Fat File routines can probably run fine before FreeRTOS is started, the SD card driver may be a very different issue. Unless is has code to change how it operates before the OS is up, it may well need interrupts and blocking calls, which won’t work before the scheduler. It may well be best to start the FreeRTOS scheduler to read the information, and when start up (or have them block) the parts that need that data. I would tend not to make that initalization task just suspend itself, but have the initialization code just continue on to some other, if possible related, operation to avoid wasting the resources of that task.

Richard, I believe you are correct that the SD driver needs to scheduler running. While it is waiting for the card detect to occur it tries to access the pxCurrentTCB and it is NULL so a Hard Fault is generated. Is there a way to create all but one of my tasks suspended and after the task that reads SD card succeeds allow the other tasks to unsupend? Is there a Semaphore that can block each task from running and then is release by the SD card task? thanks

It sounds like what you want to do is just create one task initially, and then after you read the data to create the other tasks. The other option would be to create an event group, and have all the tasks block on it to wait for the SD Card task to notify everyone that the config is setup. That would allow other tasks to do some setup that they need before needing the config data.