UART interrupt call k_fifo_put does not take effect

[sunnyyang]

cpu info:nrf5340

software:nrf connect sdk 1.6.1

hi professor,

In the uart interrupt I call k_fifo_put to trigger rx process thread but it is not take effect.What person cause this question?

[Vidar Berg]

Hello,

Have you verified through debugging that k_fifo_put() actually gets called?

Thanks,

Vidar

[sunnyyang]

I'm sure k_fifo_put was called.

[Vidar Berg]

Ok, I don't see any obvious reasons for why the rx thread is not being executed. Does k_fifo_put() keep getting called for every RX event, and does the program continue to run without crashing?

Please make sure CONFIG_ASSERT is set to 'y' in your project and provide me with debug debug logs if you have any. It would also be helpful if you could provide a minimal example so I could try to debug this here.

[sunnyyang]

I added a global variable to record the code execution process.Now I show u.

In uart irq I set the global variable 9.

In gpio irq I set the global variable 10.

In rx process thread I set SENSOR_GPS_TS_TOGGLE 1 and SENSOR_GPS_REV_DONE value 12.

The SENSOR_GPS_TS_TOGGLE is triggered by gpio irq and the SENSOR_GPS_REV_DONE is triggered by uart irq.

The code execution sequence is 9->12->10->1.But actually the code execution sequence is 9->10->12->1.

[Vidar Berg]

This shows that your rx thread is indeed running, just not in the order you expected it to. But how to you confirm what the actual interrupt sequence is? I notice that the timestamp at 47 and 49 are the same which indicates that both interrupts were triggered simultaneously.

[sunnyyang]

But how to you confirm what the actual interrupt sequence is? --- The number 9 indicates uart irq running. The number 10 indicates gpio irq running.So actual interrupt sequence is 9->10. The number 9 timestamp is 2375092975 ns.The number 10 timesatmp is 3370454303 ns. That's meaning uart irq not trigger rx process thread unitl gpio irq was called.

[Vidar Berg]

I see. So the uart irq is not processed until after gpio irq, even though the uart irq came first. 

Is your UART IRQ configured as a Zero latency interrupt by any chance? The documentation states that you should not use kernel APIs from such interrupts and that it can lead to undefined behavior.

[sunnyyang]

I use the "IRQ_DIRECT_CONNECT(SPIM0_SPIS0_TWIM0_TWIS0_UARTE0_IRQn, 0, nrfx_uarte_0_irq_handler,0)" to init uart irq. It is zero latency interrupt. But I use the "IRQ_CONNECT(SPIM0_SPIS0_TWIM0_TWIS0_UARTE0_IRQn, 0, nrfx_uarte_0_irq_handler, NULL, 0)" to init uart irq. The problem remains.So How to init uart irq? Actually I don't need zero latency interrupt. 

[Vidar Berg]

Please pass 'nrfx_isr' to the IRQ_CONNECT() macro like we do in our nrfx sample here: https://github.com/nrfconnect/sdk-zephyr/blob/c3208e7ff49d22d8271f305344382e9306fdde99/samples/boards/nrf/nrfx/src/main.c#L37

[sunnyyang]

According to the link, I use the "IRQ_CONNECT(SPIM0_SPIS0_TWIM0_TWIS0_UARTE0_IRQn, 0, nrfx_isr, nrfx_uarte_0_irq_handler, 0)" to init uart irq.But the problem remains.

[Vidar Berg]

Thanks for confirming. But I'm afraid I can't think of anything else that can cause this behavior. Are you able to share the rest of your code or create a minimal sample that will allow me to reproduce this here?

Edit: Can you show the struct declaration for sensor_operate_t ?

[sunnyyang]

peripheral_0822_b.rar

typedef struct
{
void *fifo_reserved;
uint32_t uiSensorState;
}sensor_operate_t;