I am encountering an anomaly with the RTOS kernel that has totally baffled me. I am working on a Cortex M7 processor using LWIP sockets and a buffer library that precludes the possibility of concurrent buffer modification. I am highly confident that all of this code is working flawlessly. memcpy is used throughout the code and everything works exactly as it should until I send an instruction for the processor to store a data block in flash.
This performance drop can be seen best from the Wireshark trace. The red line is the rate at which the processor is polled and the grey line represents the rate at which the processor responds to polls.
Initially, the response rate is equal (or close to) to the poll rate as it should always be. However, after each command to save its configuration settings in flash the response rate sharply declines and then stabilizes at a lower rate! I am totally baffled by this.
When the memory block is written to flash, a few dozen memcpy operations are performed to generate the stash and write page buffers that are then saved to flash. The block of data being written to flash is ~5 kB. All of the memcpy calls and the writing of the buffer to flash are performed by the same thread. An additional mutex is used on the flash level interface to prevent concurrent access to the flash controller or it’s set of memory.
All tasks involved in memory transfer have a floating-point context
and configUSE_TASK_FPU_SUPPORT is set to 0.
An interesting note? placing a taskENTER_CRITICAL()-taskEXIT_CRITICAL() around the write function often results in a hard fault.
Can anyone explain this type of behavior, what’s causing it, or how it can be avoided?