Interrupt triggered with no event bit set

Hi everyone

In some situations (code related, unable to tell why) when sending a frame, the receiving device triggers an interrupt with SYS_STATUS_ID set to 0x00800002. I wonder why an interrupt is triggered with no event bit set, but I did not fully understand under which circumstances the SYS_STATUS_SLP2INIT bit is set.

The problem however is, that no RX related bit is set, although the interrupt was clearly triggered by a TX event of another device and when ignoring the fact, that no bit was set, I can read the RX buffer and it contains the correct data that was sent originally.
A workaround to that is sending the same frame twice within a short amount of time, but on the long run this is not a suitable solution.

My questions are:
1. Under which circumstances is the SYS_STATUS_SLP2INIT bit triggered?
2. What could be the reason that no RX bit (not even error) is set but I can load data from the buffer that is correct?

Thanks for any insight about this issue.

Do you have auto RX re-enable set?

How do you know you are not reading previous frame?

If the RX event is not set, then the RX buffer will contain previously received frame.

Z

Yes.

Because the data is the one that was sent at the TX event of another node (i.e. the data is different than previous RX data).

Can you tell me under which circumstances the IC switches from SLEEP to INIT mode?

When using auto re-enable the error events (e.g. SFD TO, PHR error etc.) can give rise to “phantom” interrupts, or glitches on the IRQ line, as the device will trigger SFD TO or PHE but then re-enable RX and clear the event.

SLEEP to INIT, when device is woken up and transitions from SLEEP state to INIT state. (it will then automatically transition to IDLE once PLL locks)

Hi, I am having a similar problem, except I do not have auto RX re-enable set.

What are scenarios where the SYS_STATUS register gets cleared? I am thinking about this as I type…

It may have something to do with the way I am scheduling the handling of an IRQ in my RTOS. I have a periodic scheduler for a TDMA radio scheme, and every time slot will either set RXENAB or TXSTRT depending if we are in a receive or transmit time slot. If I have an anchor set to receive on the next time slot, and if the scheduler is slightly behind the coordinator, my current code may set RXENAB in the SYS_CTRL register AFTER the receiver starts receiving a frame from the transmitter, if the transmitter is a little ahead of the receiver’s time slot.

This makes perfect sense.

Are there any other triggers that cause the SYS_STATUS register to clear besides the SYS_CTRL register? Say I have a task that is reading/writing registers on the DW1000 in the background, and I get a DW IRQ. Are there any other registers to look out for that may clear the SYS_STATUS IRQ prior to my handling?

Hi Lincoln,

I would just warn you to be careful, to make sure you don’t issue commands (TX or RX) if the DW1000 is already in TX or RX, make sure the device is in IDLE (can do TRXOFF) and then issue a new command. If you issue new commands while device is not finished, this can clear STATUS and confuse your event handlers.

If you have multiple threads reading/writing to DW1000… make sure you have proper protection, so that the SPI transaction from one thread does not get interrupted by another.

Hi Zoran, thanks. I should be more clear, I am doing a TRXOFF prior to issuing a TXSTRT or RXENAB.

I’m guessing the TRXOFF will clear the status register? Or is it the TX or RX command that clears it?

Hi

TRXOFF does not clear events. It just puts DW1000 to IDLE. if you use dwt_forcetrxoff API function then the events will also be cleared.