St25r3917b workerstate stuck in state 2

[LCHAN.41]

Hello, i am developing a firmware on EFR32 platform, most problem were solve and the st25r3917b could communicate with the EFR32 via I2C.However , something weird happened when i migrate code from a testboard to a actural board.
1. The code works perfectly in STM platform, when the card put on it , it can scan it every cycle.But then i migrated the code on EFR32 platform testboard, the reader only sometime could read the card and the UID.Could you help me have a glance about what is most possibly cause the difference ?

2. Although , the testboard is "semi-funcitional" , it is acceptable that i can run it on a actual integrated board. The integrated board and the EFR testboard actually is the same hardware setting(only the irq pin and I2C pin is different), but the integrate borad stuck in workerstate 2 as always, the return code always return err 4 . I am so confuse for fews day of why these two boards almost the same but one can works but another is not. Can you tell me what may cause the workerstate stuck in 2?

Here are the digital viewer of two board(STM32 and EFR testboard, the ingrated board don't have any jumpout pin so i can not provide the digital viewer graph)
CH2:SCL of EFR32
CH1:SDA of EFR32
CH0:IRQ of EFR32

CH6:SDA of STM32

CH4:SCL of STM32

CH5:irq of STM32



update: The most possible answer of why the integrated board can not work is because the IRQ in hardware actually require a higher signal inpedance, i swap i2c and irq 3pins to other pins and it works

[Ulysses HERNIOSUS]

Hi,

I was about seeing similar from the trace - software does not see the IRQ and treats it as timeout. So is your issue now solved by swapping pins?

BR, Ulysses

[LCHAN.41]

In the EFR32 integrate board, I swap three pins and then the board could behave like the performanace of the EFR32 testboard(successful rate read around 1/15).
on I2C channel i am kind of sure it should be no problem because both board of EFR32 could go through the test before the loop (VDD Test, OSC Test etc.), so the most suspicious part is the irq pin, by knowing swapping pin could run then i can eliminate the code problem. Therefore, my guess is bad signal impedance of the IRQ part.
However , low successful rate is my next problem need to solve, it may because the clock differences between STM32 and EFR32, i am not that deep in firmware programme, so i guess i just do over sampling in a short time to read RFID tag on EFR32.

[Ulysses HERNIOSUS]

Hi,

best if you share again traces then. Make sure the IRQ is properly displayed in the trace.

I was a bit confused at first that one trace contained both: EFFR32 and STM32 signals at the same time polling. I hope they are not too close to each other to influence one another.

BR, Ulysses

[LCHAN.41]

They are totally seperate board and no any connection between them, just polling them at the same time,
here is my latest wave graph for the integrated board of EFR

CH5:IRQ
CH4:SCK

CH6:SDA

[Ulysses HERNIOSUS · Accepted solution]

Hi,

it seems that RFAL goes into error handling as MCU timers expires before the interrupt is being signaled. After C8/C6 commands you often find writing interrupt mask register 16/17/18 which indicates that the function has signaled a timeout - obviously prematurely. Please make sure the platformTimer*() are implemented to wait at least for the requested time. 

It should also be useful to enable the ST25R_SELFTEST in st25r3916.c which performs some tests.

BR, Ulysses

[LCHAN.41]

Thank you for the detail direction to solve this problem, 

I will now check the MCU Watchdog and the platformTimer is setting correct or not , never thought that is the timer function cause the problem. 

I closed the ST25R_SELFTEST because the firmware always fail at the RFAL_ERR_TIMEOUT, i think it may also relate to the platformTimer. 

[LCHAN.41]

update:

I change uDiff = (timer - platformGetSysTick()); to uDiff = (timer+100 - platformGetSysTick());
then the read successfully rate problem tackled, really great appericiate for the help