CMSIS-RTOS的osMailFree()返回某个地址，而不是osStatus类型的值 [英] CMSIS-RTOS's osMailFree() returns some address instead of osStatus-type value

问题描述

所以我将CMSIS-RTOS邮件队列机制与在180MHz上运行的STM32F427微控制器上的Keil uVision 5.0.5一起使用.而且，每时每刻使用osMailFree()释放先前分配的邮箱元素都会导致返回某些地址，而不是返回 osStatus 类型的值，例如 osOK 或 osErrorValue 或文档中所说的任何内容.

So I'm using CMSIS-RTOS mail-queue mechanics with Keil uVision 5.0.5 at STM32F427 microcontroller running at 180MHz. And every now and then releasing previously allocated mailbox element with osMailFree() resulted in some address being returned instead of osStatus-type value like osOK or osErrorValue or whatever is said in the docs.

此地址指向分配给 osMailQDef 的服务结构的 os_mailQ_p _ ## blahlbah 元素.这也意味着它指向的位置超出了分配有相同 osMailQDef 宏的实际数据缓冲区的末尾.

This address points to os_mailQ_p_##blahlbah element of a service structure allocated with osMailQDef. This also means it points right beyond the end of an actual data buffer allocated with the same osMailQDef macro.

我所有的结构都是静态分配的；线程的堆栈大小(OS_STKSIZE 600)看起来也足够漂亮-无论如何，将它们加倍和三倍都没有效果.

All of my structures are allocated statically; stack sizes for threads (OS_STKSIZE 600) are also looking pretty enough - anyway, doubling and tripling them gave no effect.

如果不是一个线程无法分配邮件元素( osMailAlloc()返回0)而另一个线程却在某个程序的早期或之后出现这种情况，这不会打扰我，等待线程，持续占用 osEventTimeout .似乎所有内存块都在使用中-但老实说，我每次使用后都会释放它(包装对象的析构函数，以确保它是真正释放的).

It wouldn't bother me if it's not the fact that early or later my program comes into situation when one thread is unable to allocate a mail element (osMailAlloc() returns 0) while other, waiting thread, is constantly taking osEventTimeout. Seems like all memory blocks are in use - yet I'm honestly releasing it after every use (in wrapping object's destructor, to be sure it is truly released).

这意味着什么，在哪里挖掘?

What could that mean and where to dig?

推荐答案

好吧，我没有理解所描述行为的真正深层原因是什么.但是:

Well, I didn't unsedstand what was the real in-depth reason for the behaviour described. But:

1)最初发现了一种解决方法:调用失败后立即再次调用 osMailFree()就足够了.然后，它预期会返回 osOK ，并且(如我的长期测试所示)，该时间资源已被释放.

1) At first there was found a workaround for this: it is enough to call osMailFree() once again immediately after the unsuccessull call. It then expectedly returns osOK and (as my long-term tests have shown) that time resource is being freed for real.

2)在更改了我正在使用的FatFS库的一部分的 fatfs_sd_sdio.c 文件中的IRQ优先级设置过程之后，效果完全消失了.特别是以下代码行:

2) The effect has vanished completely after I have altered IRQ priority setting procedure inside fatfs_sd_sdio.c file that is a part of FatFS library I'm using. Particularly it was the following code lines:

NVIC_PriorityGroupConfig (NVIC_PriorityGroup_1);

NVIC_InitStructure.NVIC_IRQChannel = SDIO_IRQn;
NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 1;
NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0;
NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
NVIC_Init (&NVIC_InitStructure);

NVIC_InitStructure.NVIC_IRQChannel = SD_SDIO_DMA_IRQn;
NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 1;
NVIC_Init (&NVIC_InitStructure);

替换为以下内容:

NVIC_EnableIRQ(SDIO_IRQn);
NVIC_SetPriority (SDIO_IRQn, 0x0e);
NVIC_EnableIRQ(SD_SDIO_DMA_IRQn);
NVIC_SetPriority (SD_SDIO_DMA_IRQn, 0x0e);

其中 0x0E 是RTX SysTick的优先级减去1.值得注意的是，直到我摆脱了NVIC_PriorityGroupConfig()呼叫，该治愈最初并未显得十分重要，治愈还是没有完成我.

where 0x0E is a RTX SysTick's priority level minus 1. It is notable that the cure wasn't complete until I got rid of NVIC_PriorityGroupConfig() call that initially seemed of no significant importance for me.

这篇关于CMSIS-RTOS的osMailFree()返回某个地址，而不是osStatus类型的值的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！