AM2434: 高优先级中断，阻止低优先级中断状态更新，是BUG吗？？？

高优先级中断，阻止低优先级中断状态更新，是BUG吗？？？

R5程序中，PRU和MMC中断，PRU优先级比MMC高，在PRU中断程序里，与MMC外设通讯，MMCSD1_NORMAL_INTR_STS（Normal Interrupt Status Register，0FA0 0030h）和MMCSD1_ERROR_INTR_STS（Error Interrupt Status Register，0FA0 0032h）寄存器，里面的中断状态没有更新，请问是怎么回事？所有中断，我都Enable了的。

li ljch：

AM243x在设置优先级后，应该可以中断嵌套吧？？？

,

Shine：

如果没有使能PRU中断，MMC中断能发生吗？

,

li ljch：

可以的

,

Shine：

已把您的问题升级到英文e2e论坛，请关注下面帖子的回复。https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1200042/am2434-mmc-interrupt-can-t-be-set-in-pru-interrupt

,

Shine：

请看下面e2e工程师的回复。

Whether the MMC generates interrupts to R5F/VIM should have nothing to do with whether the PRU also generates interrupts to R5F/VIM. This also has nothing to do with VIM, since you're saying the MMC peripheral itself isn't generating interrupts.

Does the MMC generate interrupts (flags set in MMCSD1_NORMAL_INTR_STS or MMCSD1_ERROR_INTR_STS) if PRU interrupts (no PRU ISR is executed) are disabled?

,

li ljch：

好的，谢谢

,

li ljch：

我使用的是TI的SDK，里面的中断，都是通过HwiP_irq_handler_c()函数来处理，同时，MMCSD1_NORMAL_INTR_STS_EN和MMCSD1_ERROR_INTR_STS_EN里面的中断都打开了的。当PRU ISR处理退出之后，是可以进入MMC ISR，关键是在PRU ISR里面，MMC通讯时，看到MMCSD1_NORMAL_INTR_STS和MMCSD1_ERROR_INTR_STS的中断标志，没有设置起来，完全被屏蔽阻断了，只有退出高优先级的PRU ISR之后，才能获得MMCSD1_NORMAL_INTR_STS和MMCSD1_ERROR_INTR_STS的中断标志。我想知道，如何才能在高优先级的中断ISR，获得低优先级的中断状态标志？？？或者说，有没有可能？？？

,

Shine：

已把您的问题更新到e2e帖子，请关注帖子的回复。

,

Shine：

请看下面e2e工程师的回复。

I assume you're using IRQs and you're referring to the VIM PRU (ICSSG) vs MMC interrupt priority. Is this correct?

The VIM priority for an interrupt has no effect on the interrupt status bits generated in a peripherial register (here MMC).

Are you using No RTOS? According to the documentation, No RTOS support IRQ interrupt nesting: https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/08_05_00_24/exports/docs/api_guide_am243x/KERNEL_NORTOS_PAGE.html#autotoc_md490

Is the PRU ISR interrupting the MMC ISR (since it's lower priority) after MMC ISR has cleared the MMC status registers? After exiting the PRU ISR, the MMC ISR would resume.

,

li ljch：

I assume you're using IRQs and you're referring to the VIM PRU (ICSSG) vs MMC interrupt priority. Is this correct?是的。我是在PRU ISR里面关闭了所有中断，再使用MMC外设发起通讯，同时检查MMC外设的中断状态，对方也是可以正确收到数据，MMC肯定是应该有发送完成中断状态置1才对，但检查MMCSD1_NORMAL_INTR_STS和MMCSD1_ERROR_INTR_STS，看不到MMC中断状态置1。

,

Shine：

已把您的问题在e2e帖子上更新，请关注帖子的回复。

,

li ljch：

好的，谢谢

,

Shine：

不客气~请看下面e2e工程师最新的回复。

What is the behavior if you disable PRU interrupts entirely and perform the MMC processing you're currently experimenting with in PRU ISR inside the MMC ISR? Do you see the behavior you expect?

What if you set the PRU & MMC ISRs to the same interrupt priority?

Can you send me a toy example that shows the behavior so I can better you you with debug?

,

li ljch：

完全禁止PRU中断，MMC中断状态功能是正常的，MMC在发送完数据后，可以获得MMCSD1_NORMAL_INTR_STS中XFER_COMPLETE的状态改变，即置1，这正是我所需要的。另外，我没有合适的，可以展示这个问题的例程，抱歉

,

Shine：

li ljch 说：另外，我没有合适的，可以展示这个问题的例程，抱歉

方便发一下相关的配置代码么？

,

li ljch：

这是MMC的SDIO配置，不在PRU ISR里面，MMC收发数据，是可以看到XFER_COMPLETE的状态改变

{ .ssBaseAddr = CSL_MMCSD1_SS_CFG_BASE, .ctrlBaseAddr = CSL_MMCSD1_CTL_CFG_BASE, .inputClkFreq = 200*1000000U, .outputClkFreq = 4*1000000U, .ClockEdge = SDIO_CLOCK_EDGE_FALLING, .enableDma = TRUE, .intrEnable = TRUE, .intrNum = 166U, .busWidth = SDIO_WIDTH_4BIT, .busVoltage = SDIO_VOLT_3_3V, .Callback = SDIO_IRQHandler, },

MMCSD1_NORMAL_INTR_STS_ENA = 0xffff;MMCSD1_ERROR_INTR_STS_ENA = 0xffff;MMCSD1_NORMAL_INTR_SIG_ENA = 0xffff;MMCSD1_ERROR_INTR_SIG_ENA = 0xffff;

static void SDIO_IRQHandler(void *arg){

const SDIO_Attrs *sdioAttrs = (const SDIO_Attrs *)arg; const CSL_mmc_ctlcfgRegs *pReg = (const CSL_mmc_ctlcfgRegs *)(sdioAttrs->ctrlBaseAddr);

uint16_t regErr = 0U; uint16_t regNor = 0U; uint16_t respVal[8] = {0};

regErr = CSL_REG16_RD(&pReg->ERROR_INTR_STS); regNor = CSL_REG16_RD(&pReg->NORMAL_INTR_STS);

if(regNor & CSL_MMC_CTLCFG_NORMAL_INTR_STS_CMD_COMPLETE_MASK) {flgResp=1; }

if(regNor & CSL_MMC_CTLCFG_NORMAL_INTR_STS_BUF_RD_READY_MASK) { flgResp=2; }

CSL_REG16_WR(&pReg->ERROR_INTR_STS, 0xffff); CSL_REG16_WR(&pReg->NORMAL_INTR_STS, 0xffff);

}

static uint16_t SDIO_StateCode(){

const CSL_mmc_ctlcfgRegs *pReg = (const CSL_mmc_ctlcfgRegs *)(gSdioAttrs->ctrlBaseAddr);

uint16_t regErr; uint16_t regNor; uint16_t resCode = 0;

regErr = CSL_REG16_RD(&pReg->ERROR_INTR_STS); regNor = CSL_REG16_RD(&pReg->NORMAL_INTR_STS);

if(regNor & CSL_MMC_CTLCFG_NORMAL_INTR_STS_CMD_COMPLETE_MASK) { resCode=1; }

if(regNor & CSL_MMC_CTLCFG_NORMAL_INTR_STS_BUF_RD_READY_MASK) { resCode=2; }/* CSL_REG16_WR(&pReg->ERROR_INTR_STS, 0xffff); CSL_REG16_WR(&pReg->NORMAL_INTR_STS, 0xffff);*/ return resCode;

}

,

Shine：

请看下面e2e工程师的回复。

I looked at the SDK 08.05 MMCSD driver. I'm not an expert in this driver, but from what I can determine, interrupt mode isn't supported.

Sysconfig has no "interrupt enable" switch. Generated code sets gMmcsdAttrs[0].intrEnable to FALSE.
Inside the driver (<SDK>\source\drivers\mmcsd\v0\mmcsd_v0.c:MMCSD_open(), MMCSD_isr() is registered if attrs->intrEnable is TRUE.
MMCSD_isr() is an empty function.

Also, looking at the SDK release notes, I see the comment "Interrupt mode not tested" for the MMCSD R5F driver: https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/08_05_00_24/exports/docs/api_guide_am243x/RELEASE_NOTES_08_05_00_PAGE.html

I'm looping in an MMCSD driver expert for further comment in case I'm mistaken.

What SDK software is the customer using for MMCSD transfers? How is the customer enabling and registering interrupts for the MMCSD software?

I want to make sure I understand what the customer is trying to do. Can you please confirm my summary below is correct?

Summary:

Software executing on R5F.
Using MMCSD1.

Using MMCSD1_EMMCSDSS_INTR_0 input on VIM, routed to IRQ.
Interrupt enabled.

Using ICCSGn,PRUm.

Using one of PRU_ICSSG0_PR1_HOST_INTR_PEND_0-7 interrupt inputs on VIM, routed to IRQ.
Interrupt enabled.

PRU interrupt is set as higher priority than MMCSD interrupt.
Inside PRU ISR:

MMCSD is used for read and/or write.
Customer expects MMCSD1_NORMAL_INTR_STS bits to be updated while inside PRU ISR after MMCSD read/write is complete. These status register bits aren't updating as expected inside the PRU ISR.
Customer needs MMCSD1_NORMAL_INTR_STS bits to update inside PRU ISR for proper operation of code.

Customer disabled MMCSD interrupts, observes same behavior in PRU ISR. This seems to indicate interrupt nesting isn't causing the issue.
If PRU interrupts are disabled, MMCSD behaves normally. MMCSD1_NORMAL_INTR_STS bits are set correctly after read/write completes.

How is the customer determining the MMCSD1_NORMAL_INTR_STS bits aren't set inside the PRU ISR?

Inside the PRU ISR, what are the values of these registers:

MMCSD1_NORMAL_INTR_SIG_ENA
MMCSD1_NORMAL_INTR_STS_ENA

What is the value of these registers if the MMCSD read/write is invoked outside the PRU ISR?

Does the customer see the same behavior if another interrupt is used intead of PRU, e.g. DMTimer?

,

li ljch：

What SDK software is the customer using for MMCSD transfers?我用的SDK是8.5.0.24

How is the customer enabling and registering interrupts for the MMCSD software?

HwiP_Params hwiPrms; if((sdioAttrs->intrEnable == TRUE) && (sdioAttrs->Callback != NULL)) { HwiP_Params_init(&hwiPrms); hwiPrms.intNum = sdioAttrs->intrNum; hwiPrms.callback = sdioAttrs->Callback; hwiPrms.args = (void *)sdioAttrs; hwiPrms.priority = 0x03; status = HwiP_construct(NULL, &hwiPrms); }

How is the customer determining the MMCSD1_NORMAL_INTR_STS bits aren't set inside the PRU ISR?

MMC发送完数据后，直接连续读取MMCSD1_NORMAL_INTR_STS ，看XFER_COMPLETE是否置1.

What is the value of these registers if the MMCSD read/write is invoked outside the PRU ISR?

已更新，图片也可以右键在新标签页打开查看

,

Shine：

最后的图片显示不出来，请回复是点击“插入”图片。

,

li ljch：

已更新，图片也可以右键在新标签页打开查看

,

Shine：

已更新到e2e帖子，请关注帖子的回复。

,

Shine：

请看下面e2e工程师的回复。

I understand the customer is using their own SDIO driver. Is that correct?

Can you please confirm my above summary is correct?

Thanks for sharing MMCSD1_NORMAL_INTR_SIG_ENA / MMCSD1_NORMAL_INTR_STS_ENA outside the PRU ISR. From your snapshot, I understand:

MMCSD1_NORMAL_INTR_SIG_ENA = 0x7FFF
MMCSD1_NORMAL_INTR_STS_ENA = 0x7FFF

What are the values of these registers inside the PRU ISR?

Does the customer see the same behavior if another interrupt is used instead of PRU, e.g. DMTimer? This should be a simple experiment for them.

I can't think of a reason MMCSD status register updates would be masked (or not update) inside an ISR (PRU or otherwise). I don't think this has anything to do with PRU host interrupts, R5F VIM, or the SDK IRQ handler.

I'm reassigning this thread to a colleague with more expertise on MMCSD.

,

li ljch：

Summary:

Software executing on R5F.是的
Using MMCSD1.

Using MMCSD1_EMMCSDSS_INTR_0 input on VIM, routed to IRQ.是的
Interrupt enabled.是的

Using ICCSGn,PRUm.

Using one of PRU_ICSSG0_PR1_HOST_INTR_PEND_0-7 interrupt inputs on VIM, routed to IRQ.

PRU_ICSSG1_PR1_HOST_INTR_PEND_1，PRU_ICSSG1_PR1_HOST_INTR_PEND_2，PRU_ICSSG1_PR1_HOST_INTR_PEND_3，PRU_ICSSG1_PR1_HOST_INTR_PEND_4

Interrupt enabled.是的

PRU interrupt is set as higher priority than MMCSD interrupt.

是的，PRU=1，MMCSD=15。当MMCSD优先级改成其他，比如4，也是一样结果

Inside PRU ISR:

MMCSD is used for read and/or write.是的
Customer expects MMCSD1_NORMAL_INTR_STS bits to be updated while inside PRU ISR after MMCSD read/write is complete. These status register bits aren't updating as expected inside the PRU ISR.是的
Customer needs MMCSD1_NORMAL_INTR_STS bits to update inside PRU ISR for proper operation of code.是的

Customer disabled MMCSD interrupts, observes same behavior in PRU ISR. This seems to indicate interrupt nesting isn't causing the issue.

MMCSD1_NORMAL_INTR_STS状态位XFER_COMPLETE，不能更新置1

If PRU interrupts are disabled, MMCSD behaves normally. MMCSD1_NORMAL_INTR_STS bits are set correctly after read/write completes.是的

,

li ljch：

What are the values of these registers inside the PRU ISR?

Does the customer see the same behavior if another interrupt is used instead of PRU, e.g. DMTimer? 

这个是可以的。

,

Shine：

请看下面e2e工程师的回复。

To analyze the problem more in depth, can the customer share the project where the problem is replicated ? This will save us some time in recreating the project. Customer can choose to remove all their proprietary SW and replicate the issue on a vanilla software from SDK code base.

This will really speed-up the debug by a few days.

,

Shine：

请看下面e2e另外一位工程师的回复，最好能提供一个project方便工程师复现您的问题，谢谢！

Thanks for the response.

From your snapshot, I understand MMCSD1_NORMAL_INTR_SIG_ENA/MMCSD1_NORMAL_INTR_STS_ENA have these settings inside the PRU ISR:

MMCSD1_NORMAL_INTR_SIG_ENA = 0x7FFF
MMCSD1_NORMAL_INTR_STS_ENA = 0x7FFF

These look normal.

Shine said:
Yes, DMTimer can run correctly.

To be clear, when you take the DMTimer ISR, you're able to use your MMCSD software inside the ISR and the MMCSD behaves correctly? I assume you've set the DMTimer interrupt priority to the same as the PRU ISR (when it's built into the code)? This suggests there is some issue with PRU interrupts.

I agree with Aakash and I'm again requesting an example demonstrating this behavior. I understand the customer has written custom MMCSD driver software. Also, it would be difficult for us to recreate this using SDK MMCSD APIs since they don't currently support interrupt mode (Aakash, please confirm).

,

Shine：

请看下面e2e工程师的回复。For starters, if we could get hands on an example that works with PRU and DMTimer that would be good start for us as well. We might need more information on how the MMCSD changes are required, but this will enable us to support better.

,

li ljch：

To be clear, when you take the DMTimer ISR, you're able to use your MMCSD software inside the ISR and the MMCSD behaves correctly?是的

I assume you've set the DMTimer interrupt priority to the same as the PRU ISR (when it's built into the code)? 优先级分别是，PRU=1，DMTimer=4，MMCSD-SDIO=0x0f

,

Shine：

能否提供一下project工程文件，方便工程师复现您的问题，谢谢！

,

li ljch：

不好拆的开，暂时无法提供，抱歉