2021-02-26 04:42 AM
In project based on exampleRfalPoller.c from library ST25NFC_Embedded_Lib_ST25R3916 and X-NUXLEO-NFC06A1 board I have problem with detection NFC-V tags.
After
rfalNfcvPollerInitialize(); /* Initialize RFAL for NFC-V */
rfalFieldOnAndStartGT(); /* As field is already On only starts GT timer */
err = rfalNfcvPollerCheckPresence( &invRes ); /* Poll for NFC-V devices */
I always get err=4 (ERR_TIMEOUT)
Error is detected in file rfal_rfst25r3916.c, line 2190:
case RFAL_TXRX_STATE_RX_WAIT_RXS:
irqs = st25r3916GetInterrupt( (ST25R3916_IRQ_MASK_RXS | ST25R3916_IRQ_MASK_NRE | ST25R3916_IRQ_MASK_EOF) );
if( irqs == ST25R3916_IRQ_MASK_NONE )
{
break; /* No interrupt to process */
}
/* Only raise Timeout if NRE is detected with no Rx Start (NRT EMV mode) */
if( ((irqs & ST25R3916_IRQ_MASK_NRE) != 0U) && ((irqs & ST25R3916_IRQ_MASK_RXS) == 0U) )
{
//here this error is set
gRFAL.TxRx.status = ERR_TIMEOUT;
gRFAL.TxRx.state = RFAL_TXRX_STATE_RX_FAIL;
break;
}
Tags NFC-A are detected correctly, so communication with ST25R3916 should be OK.
What can I do, to detect this tags correctly?
Sorry for may English - it's not my native language :)
Solved! Go to Solution.
2021-03-08 07:41 AM
Hi pagano.paganino,
No educated guesses from our side. You could check blindly some things: Check rfalAnalogConfigInitialize() is called in your code, check the protection macros in platform.h which should prevent concurrent access to SPI driver from ISR and main level - maybe you changed the INT pin connection and the macro is not ensuring mutual access anymore.
Otherwise please provide logic analyzer traces for inspecting what is happening.
Regards, Ulysses
2021-03-10 06:01 AM
Hello, thanks for Your help, but there must be something else.
I2C communication is OK, I can read FIFO, and its content is exactly as saved before.
Wave on antenna coil looks like manchester coding, and is inconsistent with the ISO/IEC 15693-2 standard (data coding mode 1 out of 4).
In rfal_rfst25r3916.c there are commands:
/* Set Analog configurations for this bit rate */
rfalSetAnalogConfig( (RFAL_ANALOG_CONFIG_TECH_CHIP | RFAL_ANALOG_CONFIG_CHIP_POLL_COMMON) );
rfalSetAnalogConfig( (rfalAnalogConfigId)(RFAL_ANALOG_CONFIG_POLL | RFAL_ANALOG_CONFIG_TECH_NFCV | rfalConvBR2ACBR(gRFAL.txBR) | RFAL_ANALOG_CONFIG_TX ) );
rfalSetAnalogConfig( (rfalAnalogConfigId)(RFAL_ANALOG_CONFIG_POLL | RFAL_ANALOG_CONFIG_TECH_NFCV | rfalConvBR2ACBR(gRFAL.rxBR) | RFAL_ANALOG_CONFIG_RX ) );
where rfalConvBR2ACBR(gRFAL.txBR) and rfalConvBR2ACBR(gRFAL.rxBR) = RFAL_ANALOG_CONFIG_BITRATE_1OF4
but in rfalAnalogConfigCustomSettings[] (analogConfigTbl_NFC06A1.h) there are no records with these identifiers (10C1 and 10C2). Maybe this is a problem?
2021-03-10 07:44 AM
Hi Piotr,
if it is something systematic in the software as you are suggesting then it should happen both for your PIC32 based sw and our STM32L4 based software.
IMO we are looking into issues caused by porting. One of:
Sometimes not all analog config identifiers are use / filled with register settings.
Regards, Ulysses
2021-03-11 01:11 AM
Finally found the cause of the problem:
In rfal_iso15693_2.c compiler didn't initialize stream_config structure. I added few lines, and now NFC-V tags are recognizes correctly.
ReturnCode iso15693PhyConfigure(const iso15693PhyConfig_t* config, const struct iso15693StreamConfig ** needed_stream_config )
{
static struct iso15693StreamConfig stream_config = { /* MISRA 8.9 */
.useBPSK = 0, /* 0: subcarrier, 1:BPSK */
.din = 5, /* 2^5*fc = 423750 Hz: divider for the in subcarrier frequency */
.dout = 7, /*!< 2^7*fc = 105937 : divider for the in subcarrier frequency */
.report_period_length = 3, /*!< 8=2^3 the length of the reporting period */
};
/* added lines: */
stream_config.useBPSK = 0;
stream_config.din = 5;
stream_config.dout = 7;
stream_config.report_period_length = 3;
/* make a copy of the configuration */
ST_MEMCPY( (uint8_t*)&iso15693PhyConfig, (const uint8_t*)config, sizeof(iso15693PhyConfig_t));
if ( config->speedMode <= 3U)
{ /* If valid speed mode adjust report period accordingly */
stream_config.report_period_length = (3U - (uint8_t)config->speedMode);
}
else
{ /* If invalid default to normal (high) speed */
stream_config.report_period_length = 3;
}
*needed_stream_config = &stream_config;
return ERR_NONE;
}
Now I have to check in compiler manual why this behavior happen, and check if there are other places in code which can be affected by this problem.
Thank you for your help and commitment!
Regards,
Piotr
2021-03-11 01:19 AM
Hi Piotr,
which compiler do you use? and which version?
Rgds
BT
2021-03-11 02:03 AM
It's XC32 Compiler v2.50 from Microchip.
Code works properly also if this structure IS NOT declared as static:
ReturnCode iso15693PhyConfigure(const iso15693PhyConfig_t* config, const struct iso15693StreamConfig ** needed_stream_config )
{
struct iso15693StreamConfig stream_config = { /* MISRA 8.9 */
.useBPSK = 0, /* 0: subcarrier, 1:BPSK */
.din = 5, /* 2^5*fc = 423750 Hz: divider for the in subcarrier frequency */
.dout = 7, /*!< 2^7*fc = 105937 : divider for the in subcarrier frequency */
.report_period_length = 3, /*!< 8=2^3 the length of the reporting period */
};
/* make a copy of the configuration */
ST_MEMCPY( (uint8_t*)&iso15693PhyConfig, (const uint8_t*)config, sizeof(iso15693PhyConfig_t));
if ( config->speedMode <= 3U)
{ /* If valid speed mode adjust report period accordingly */
stream_config.report_period_length = (3U - (uint8_t)config->speedMode);
}
else
{ /* If invalid default to normal (high) speed */
stream_config.report_period_length = 3;
}
*needed_stream_config = &stream_config;
return ERR_NONE;
}
By the way - why this struct was declared as static?
Regards,
Piotr
2021-03-11 02:10 AM
Hi Piotr,
defining it as static saves a bit of stack and a bit of code. But no hard reason why it must be static. As a pointer to this struct is returned it must not be on the stack. Instead of function static it could also be global.
This struct in its original version should end up in R/W section - please check if your startup code correctly copies the R/W ROM section to RAM?
Regards, Ulysses
2021-03-11 02:26 AM
Hi Piotr,
MPLAB XC32 C/C++ Compiler conforms to C89 standard (see user guide §7). "Some features from the later standard, C99, are also supported. " Designated initializers in arrays or structures is a C99 feature. Therefore the support of this feature in this compiler may be limited. I would suggest to contact the provider of this compiler to report this problem.
if you remove the static qualifier, I would suggest to make sure to have this structure as a global (as a pointer to this structure is used).
Rgds
BT