cancel
Showing results for 
Search instead for 
Did you mean: 

ST25R3916 Chip ID Check Fails on STM32L010RB – Stuck in Error Handler

Gunes
Associate II

 

Hi everyone,

I'm currently working with the X-NUCLEO-NFC08A1 expansion board and using the ST25R3916 NFC reader IC with an STM32L010RB microcontroller.

When I call rfalNfcInitialize(), the initialization process fails and enters the error handler. After some debugging, I found that the issue happens specifically at this point in the code:

if( !st25r3916CheckChipID( NULL ) )

{

platformErrorHandle();    //This is the point where the code gets stuck

return RFAL_ERR_HW_MISMATCH;

}

The st25r3916CheckChipID() function seems to fail, and the chip revision is read as 0. This causes the code to jump to platformErrorHandle() and get stuck in an infinite loop in _Error_Handler().

I checked the wiring, SPI connections, and power supply. Everything seems correct, but I still can’t figure out what is causing the chip ID check to fail. I'm using the provided driver from ST and haven’t modified the low-level SPI functions.

 

The flow reaches platformErrorHandle() when st25r3916CheckChipID() fails.
Chip revision is read as 0.

MX_X_CUBE_NFC6_Init()

   ↳ MX_NFC8_PollingTagDetect_Init()

      ↳ st25r3916CheckChipID(&rev)

         ↳ platformErrorHandle()

Has anyone faced a similar issue or have any suggestions on what might be wrong or what else I can check?

Thank you in advance!

Note: I'm still a student and learning, so any extra explanation would be appreciated :smiling_face_with_smiling_eyes:

1 ACCEPTED SOLUTION

Accepted Solutions
Brian TIDAL
ST Employee

Hi,

I would suggest to enable ST25R_SELFTEST and ST25R_SELFTEST_TIMER switches to check that the porting to your MCU is properly functional. Just recompile your code with those 2 switches defined and check the return code of st25r3916Initialize. Also check your SPI configuration (in particular SPI CLKPhase should beSPI_PHASE_2EDGE).

Rgds

BT

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

View solution in original post

5 REPLIES 5
Ulysses HERNIOSUS
ST Employee

Hi,

first step: hook up a logic analyzer on SPI and IRQ and see what goes out vs what should go out based on Datasheet of ST25R3916B. Also possible: Use a scope with min 4 channels.

BR, Ulysses

Brian TIDAL
ST Employee

Hi,

I would suggest to enable ST25R_SELFTEST and ST25R_SELFTEST_TIMER switches to check that the porting to your MCU is properly functional. Just recompile your code with those 2 switches defined and check the return code of st25r3916Initialize. Also check your SPI configuration (in particular SPI CLKPhase should beSPI_PHASE_2EDGE).

Rgds

BT

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

First of all, thank you for your response. 
 I solved the previous SPI-related problem, but now I'm encountering other issues. I suspect I have errors in my configuration. I'd like to ask how to properly configure it. Also, I want to briefly share the error I'm currently seeing.

 

However, I've now run into another issue:
When I call the functions in the following order:

 
HAL_Init();
SystemClock_Config();
MX_GPIO_Init();
MX_X_CUBE_NFC6_Init();

The system gets stuck inside this function:

uint32_t timerCalculateTimer(uint16_t time)
{
return (platformGetSysTick() + time);
}

But if I change the order to:

 
HAL_Init();
MX_X_CUBE_NFC6_Init(); // <- works fine

...then everything works, which suggests that something in the clock configuration is breaking the SysTick timer.

 

Additionally, I ran the following code:

 
HAL_Init();
SystemClock_Config(); // Re-adding clock configuration
uint32_t tick1 = HAL_GetTick();
HAL_Delay(1000); // Wait for 1 second
uint32_t tick2 = HAL_GetTick();
printf("Tick: %lu -> %lu", tick1, tick2);

And when I checked the difference between tick1 and tick2, I found that tick1 is 1 while tick2 is 1002, indicating that there’s actually no issue with the SystemClock_Config.

I don't have a logic analyzer so I can't solve the problems completely. I will get one as soon as possible. 

Brian TIDAL
ST Employee

Hi,

please check the interrupt priorities. If the SysTick is used in some interrupts (e.g. for timeout management), then the Systick priority should higher than the other interrupt priority. Be aware that an higher priority value means a lower priority. I guess that the Systick priority is 15 (Fh) in your application which means that the SysTick has the lowest priority: in that case the systick handler is not called when an higher interrupt is running and the systick is not incremented. Try to set the EXTI0 priority to 1 and the Systick priority to 0.

Note: the initialization order should not be modified (First HAL_Init then SystemClock_Config and then peripheral init).

Rgds

BT

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.