Quantcast
Channel: Raspberry Pi Forums
Viewing all articles
Browse latest Browse all 4407

SDK • Adding to queue_t causes hardfault after working fine for minutes

$
0
0
Hey there,
I am currently having an issue with using the queue_t structure provided by pico_util. After a few minutes of successful operation queue_try_add causes an isr_hardfault.

My setup is as follows:
[*]There is an interrupt handler that handles a GPIO's rising edge to decode a digital signal
[*]This interrupt handler stores the received bits in a buffer
[*]When it detects the end of a packet, it checks if this packet is of interest for us and adds it to a queue_t

The interrupt handler roughly looks like this:

Code:

void edge_interrupt_handler(/*...*/) {// decode received bit...// add decoded bit to a buffer...if (buffer contains a complete packet) {if(!queue_try_add(&rx_queue, &packet)) {++packets_lost; // keep track of queue "overflow" for diagnostics}// clear buffer etc...}}
The second half happens in the main loop on core0:
[*]We loop through all packets in the queue
[*]Every packet is handled (i.e. the command contained in the packet is executed)

The main loop's body looks like this:

Code:

while (!queue_is_empty(&rx_queue)) {Packet packet;queue_try_remove(&rx_queue, &packet);// do something with "packet"}
Now here is the problem:
The application works totally fine for a couple of minutes. Packets are received, added to the queue and then handled correctly. However, after a few minutes, calling queue_try_add from the interrupt handler causes an isr_hardfault. See the attached stacktrace for more details. I have been unable to recognize any pattern, though, and the only way I was able to reproduce it was just waiting a few minutes and letting it happen.
The hardfault seems to be raised when trying to lock the queue, right here (link to github).
The debugger being at fault here seems unlikely as it only breaks when the isr_hardfault has already happened. My current suspicion is the incorrect use/understanding of the queue_t structure. The documentation of queue_t states that the queue is "interrupt safe" which made me think it is intended for pretty much exactly the use case described above. However, since locking the queue fails at some point, I assume my understanding of this queue is incomplete.

The stacktrace:
stacktrace_annotated.png
Does anyhone have an idea why this happens? Am I using queue_t correctly?
Thanks for reading.

Cheers!

PS: picoqueue::Queue is a C++ wrapper for queue_t. It can be found here. Since it does not do anything but wrap the C API, it should be irrelevant to this problem.

Statistics: Posted by penguins_can_fly — Fri Feb 23, 2024 7:22 pm — Replies 0 — Views 39



Viewing all articles
Browse latest Browse all 4407

Trending Articles