ST25R3916B + RFAL does not specify/clear an interrupt after Measure Power Supply command

[LltWc]

I'm working on porting the RFAL for ST25R3916B to an nRF5340, using the pairing example for X-NUCLEO-8. I have it all compiling and flashing correctly, but things break down during initialization here:

In rfalInitialize() -> st25r3916Initialize(), the issue occurs when trying to measure voltage with st25r3916MeasureVoltage(). After executing st25r3916ExecuteCommandAndGetResult, I get the below SPI trace. The IRQ line goes high as expected, the RFAL then sends a read request for registers 0x1A through 0x1D, and the ST25R3916B does not respond with any active IRQs and does not clear the IRQ line. This results in a memory access violation on the nRF5340. 

This is the standard, unmodified RFAL for ST25R3916/B. The DCT interrupt is enabled. The SPI trace looks exactly the same as a previous IRQ read. Is there something different about the Measure Power Supply (0xDF) command? Any help would be appreciated.

[Brian TIDAL]

Hi, 

can you enable the ST25R_SELFTEST switch and provide the Salae raw file?

Many thanks

Rgds

BT

[Ulysses HERNIOSUS]

Hi,

to me it looks there is no CS transition before sending the Read Interrupt status reg command:

Br, Ulyssses

[LltWc]

Here's the log file, it looks like the self test completes without any issues.

I hadn't noticed what Ulysses pointed out; no CS transition after the command may very well be the issue. My CS deselect port doesn't fail anywhere else, but I'm going to try a different method just in case.

[LltWc]

Whoops, here's the log file.

[Ulysses HERNIOSUS]

Hi,

csv is hard to read, better share the original Saleae file inside a zip.

The missing CS positive pulse is highly likely the reason for the Interrupt status register read not being correctly executed.

Ulysses

[LltWc]

Hi Ulysses,

I think you're right, but it's not (directly) about the missing CS positive pulse. Here's where I'm at:

1. The host sends a 0x42 to read register 02.
2. An IRQ is sent.
3. The host sends a 0x5A to read this IRQ. Instead of a 0x00 from the ST25 as usual, it sends 0x83 because from the ST25's perspective, it's still responding to the 0x42.
4. The host sends four 0xFF frames to read the four IRQ registers, and gets the IRQ (TXE in this case).
5. The IRQ goes low. Control returns to the main thread. CS goes high because the response is complete.

During step 3, the SPI peripheral attempts to put the 0x83 into a nullptr, causing a memory access exception. What I don't understand is why the next four 0xFFs were sent, as the host should have already crashed.

The .sal is attached. .zip and .sal aren't allowed, so I changed the extension to .log. Just change it from .log to .sal and it should open fine.

[Brian TIDAL · Accepted solution]

Hi,

make sure your platformProtectST25RComm/platformUnprotectST25RComm implementation is correct. Basically a SPI ongoing transfert shall not be interrupted by another SPI transfer (e.g. reading the interrupt register). An easy way is to disable the interrupt from the ST25R3916B during a given SPI transfer. On STM32 MCU where the ST25R3916B interrupt line is connected to PA0 GPIO, NVIC_DisableIRQ(EXTI0_IRQn)/NVIC_EnableIRQ(EXTI0_IRQn) is used to temporally suspend and then reenable the interrupt on PA0. A similar mechanism has to be ported to your own MCU.

Rgds

BT