SDHC Interrupt

[mircopizzichini]

Hi all

In my MQX project, I'm performing a periodic writing on a SD card. My tasks have different assigned priorities, and sometimes, depending on the current active task that calls it, SD card writing is successfull, and other times not (watchdog resets the device).

Reading the reference manual, I think that it could be the SDHC interrupt priority: I don't want that it interrupts other main operations, like an acquisition via SPI. How does it work? SDHC has its own priority or it takes the priority of the active task calling it?

I've just ported the example in Freescale_MQX_4.0\mfs\examples\sdcard into my project, and I don't know how to change this.

Thank you very much

Mirco

[RadekS]

Could you please specify exact version of your MQX?

SDHC driver use interrupts and DMA and interrupt priorities are not related to application code.

Could you please give us more information about watchdog (internal/external, how you trigger, time for triggering…)? I suppose, that you triggering watchdog by some special task. Correct?

IO operation could take some time.

Please try your code without watchdog. If everything works correctly, it is possible that task for watchdog triggering simply doesn’t have enough priority and it only waits for execution.

Please let me know range of priority levels of your tasks. Task priority levels 0~7 are reserved for MQX and you should use task priority level 8 and above (task with priority level 8 runs with the highest priority from application tasks).

Is it possible place here some simple example code which highlight described issue?

Have a great day,
RadekS

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[mircopizzichini]

I'm using MQX 4.0.2.

About priority level, I'm using all levels, starting from 2. Why shall I use levels 1-7? This point is not explained in the MQX user guide. I think this could be the problem, because now, changing the task priority of the I/O operation with another task, the problem disappeared.

[RadekS]

In fact, this point is explained in MQX User Guide. However since MQX could run on different platforms and it is highly configurable system, explanation could be quite complicated and it could be simple overlooked.

I will initialize discussion with designers whether we could add some additional simple notes to documentation.

Please check chapter 3.9 Handling Interrupts and Exceptions and mainly chapter 3.9.3.4 MQX_HARDWARE_INTERRUPT_LEVEL_MAX Configuration Parameter

“On Cortex-M4 and Cortex-A5 core based platforms, the MQX interrupt processing is designed this way. Kinetis K MCUs support 16 hardware interrupt priority levels. Internally MQX maps even levels (0, 2, 4, .., 14) for the MQX applications while odd levels (1, 3, .., 15) are used internally. MQX application interrupt levels are 0 to 7, the mapping from MQX application levels 0 to 7 to hardware priority levels (0, 2 to 14) is implemented in the _bsp_int_init() function.”

The MQX kernel implements critical sections using the ARM Cortex-M core's BASEPRI register. This allows the MQX kernel to only mask a subset of interrupts, and therefore provide a flexible interrupt nesting model. So, due to interrupt mapping, task with too high priority simply mask some interrupts.

Everything is slightly more complicated due to MQX_HARDWARE_INTERRUPT_LEVEL_MAX macro, but basic recommendation is that you should use task priority level 7 and above (Lower number is for higher priorities, e.g. prio 6 is used for RTCS task). In that case you can be sure that your task will not mask any of interrupts or important part of MQX. For details please see table Figure 3-5. BASEPRI Register Values for Different Task Priorities and Different Values of MQX_HARDWARE_INTERRUPT_LEVEL_MAX in MQX User Guide.