SPIRIT1 Missing IRQ

[lz1im]

Posted on August 25, 2015 at 08:59

Hello, again,

I perform a simple loop at one device configured WITHOUT LDCR mode and WITHOUT Timeout Mode, permanently /but not PERSISTENT/ stay on RX. At regular intervals /5sec/ SPIRIT going to transmit a packet of 50 bytes /Basic Protocol/. The other device receive that packet and whole system working, but at iregular intervals /20-30 min to couple of hours/ system stops working. At Device who transmit, I make a Loop like that:

- Fill TX FIFO, then SABORT, then LOCKTX, then TX, and Set FlagTX on MCU. Then if FlagTX is 1, I poll IRQ[0] Reg at 0xfd at SPIRIT, and wait for TX sent Interrupt. If they appear, I'm going from Tx to RX /SABORT, then Lock RX, then RX/, of course I clear FlagTX on MCU, and stay waiting for next 5sec interval. When system stop working, I see that My FlagTX is ''1'', so I think, there is missed IRQ TXsent. Is that possible? And more generally, at the datasheet there is only a short description of IRQ's, but there is no description, when IRQ is Set, who is cleared... That we call ''Detailed Description''. Maybe it is time to appear something like REFERENCE MANUAL of SPIRIT1, is'n't it?

Sincerely:

P. Pavlov, MSc, Sr Designer of Electron consortium JSC, Sofia, Bulgaria

[Nickname4815_O]

Posted on August 26, 2015 at 13:22

Hello Pavel,

If I understood well you are checking the MC_STATE after doing the Tx command and you see that the dev goes from READY to LOCK_TX to TX.

After that, if the TX state is reached you set a flag that enables a polling on the IRQ_STATUS (0xfd only) to check if TX done appears.

A continous polling to the IRQ_STATUS registers may be not safe. Since they are ReadReset registers, it is possible that a race condition will blank the bit (reading from the SPI side) while it is being written (by the internal digital SM).

In this case the interrupt is lost not for an issue or a bad functioning of the device but because of the way it is accessed.

Safer ways can be these 2:

- use a SPIRIT GPIO to be configured as interrupt and registering the TX_DONE event on the IRQ_MASK registers ( bit 2 of the bit 0x93). In this way, after the TX_DONE interrupt will be raised the GPIO you have configured as DIGITAL_OUT_IRQ, will fall (from Vdd to GND) and only at that time perform the read of the 4 IRQ_STATUS registers. In this way You will read the IRQ status only once, after the event is raised.

From the uC side you can stay in polling on the GPIO input data register or configure the EXTI to raise an interrupt to the CPU to be aware of the notification by SPIRIT.

- If you don't want to do so, you can perform a polling on the MC_state instead of IRQ_STATUS. This will be safe because that register is not subjected to race conditions.

Pelase let us know if it solves the problem.

Regards,

F.

[lz1im]

Posted on August 27, 2015 at 08:22

[lz1im]

Posted on August 27, 2015 at 08:23

[Nickname4815_O]

Posted on August 27, 2015 at 09:26

Hello Pavel,

here below some explanations.

case 1:

 

If sync is disturbed no packet will be received and the RX will never start to demodulate data pushing them into the RX FIFO. Indeed the SYNC DETECTED is an event that triggers the data reception.

If it is not detected, it means that the device will wait for the sync again remaining in RX and not switching back to READY. There is a way to 'tolerate' errors in the SYNC, meaning that if the pattern is received with a tolerated amount of bit errors the sync is declared VALID and data start to be received.

To do that a SQI threshold different from 0 must be configured (other valid values are 1, 2 or 3 meaning that 1 bit, 2 bits, 3bits error are tolearated respectively).

case 2: 

You are right. Since preamble is not considered useful data (meaning information that have a logical meaning carried by the packet) it can be also disturbed and this does not impact on the correct reception of the packet. Different is the situation where You enable the PQI check. In this case the received preamble must satisfy the PQI_THR that has been set, otherwise the packet is not received.

case 3: 

Right. a wrong length field will cause the receiver counts that number of bytes before switching to READY. Obviously using CRC, the corruption is detected because:

- if received packet is longer than real (received length value is higher than the transmitted one) a lot of garbage data will be appended to the packet and (with a very high likelihood) that garbage will not match CRC.

- if received packet is shorter than real (received length value is lower than the transmitted one) the CRC will be sampled in place of real data and again (with a very high likelihood) it will not match.

About the length width... You are right, there is a mistake in the datasheet that we will correct in the next revision of the document.

Regards,

F.

[lz1im]

Posted on August 28, 2015 at 08:31

Hello Federico,

Thanks for answer. I think, that our relartively small project, would be finished, thanks to explanation and discussion of that forum. And, of course I, and other developers, would expect next revisions of documentation, and /maybe/ an reference manual.

Best regards:

P. Pavlov