Hi!
I ported the NFC Reader Library v07.09.00 to my custom board with a K32L2 microcontroller. I was running the NfcrdlibEx4_MIFAREClassic example correctly until I tried to run other examples like NfcrdlibEx1_DiscoveryLoop or NfcrdlibEx6_LPCD (both gave some errors while running). After that, I cannot run NfcrdlibEx4_MIFAREClassic correctly anymore.
phacDiscLoop_Run function returns 0x4080. Digging into lower layers, I found that phhalHw_Pn5190_Instr_RfOn function returns 0x21C. Within this function, phhalHw_Pn5190_InstMngr_HandleCmd returns 0x1C.
What is this error?
I defined DEBUG_PRINT_RAW_DATA preprocessor symbol and I get the following data from the PN5190 in every loop of the main do...while loop:
RX: FF 02 00 01 00 FF FF FF FF
RX: FF 11 00 01 00 FF FF FF FF
RX: FF 00 00 01 00 FF FF FF FF
RX: FF 03 00 01 00 FF FF FF FF
RX: FF 80 00 04 40 00 00 00 FF
RX: FF 02 00 01 00 FF FF FF FF
RX: FF 02 00 01 00 FF FF FF FF
RX: FF 04 00 05 00 00 00 80 20
RX: FF 02 00 01 00 FF FF FF FF
RX: FF 0D 00 01 00 FF FF FF FF
RX: FF 00 00 01 00 FF FF FF FF
RX: FF 00 00 01 00 FF FF FF FF
RX: FF 10 00 01 1C FF FF FF FF
I didn't find any information regarding those error responses starting by 0x02 (PN5190_STATUS_INTEGRITY_ERROR), 0x03 (PN5190_STATUS_RF_COLLISION_ERROR) , 0x0D (PN5190_STATUS_RESOURCE_ERROR).
Are they PN5190 internal errors? Can I do something in order to fix them?
Thank you!
Hi abacus:
Could you please check the host interface? maybe the SPI not work.
Regards
Daniel
Regards
Daniel
Hi Daniel.
I saved the traces of the repeating loop with a logic analyser.
Can you spot any issue in those frames?
Is the microcontroller trying to send something just after every time there is an event from the PN5190? (0xF8 0x5E 0x00 0x20 0x00)
Thank you,
Aaron
EDIT: I added IRQ signal to the captures.
Sorry, I missed your update.
Did you solve this issue? The scope capture seems OK. please check whether the SPI signals are pull up on K32 side? and what is the spi baud on k32 side ?
Hi Daniel.
No, I couldn't solve it yet.
please check whether the SPI signals are pull up on K32 side? and what is the spi baud on k32 side ?
I don't have hardware pull-ups in SPI lines and internal pullups are disabled.
SPI baudrate is 500KHz:
#define PHDRIVER_KSDK_SPI_DATA_RATE 500000U
These are my SPI Init functions (as close to the original K82F as possible):
phStatus_t phbalReg_Init(
void * pDataParams,
uint16_t wSizeOfDataParams
)
{
spi_master_config_t g_masterConfig;
if ( (pDataParams == NULL) || (sizeof(phbalReg_Type_t) != wSizeOfDataParams))
{
return (PH_DRIVER_ERROR | PH_COMP_DRIVER);
}
((phbalReg_Type_t *)pDataParams)->wId = PH_COMP_DRIVER | PHBAL_REG_KINETIS_SPI_ID;
((phbalReg_Type_t *)pDataParams)->bBalType = PHBAL_REG_TYPE_SPI;
memset(&g_masterConfig, 0, sizeof(spi_master_config_t));
g_masterConfig.enableMaster = true;
g_masterConfig.baudRate_Bps = PHDRIVER_KSDK_SPI_DATA_RATE;
g_masterConfig.dataMode = kSPI_8BitMode;
g_masterConfig.polarity = kSPI_ClockPolarityActiveHigh;
g_masterConfig.phase = kSPI_ClockPhaseFirstEdge;
g_masterConfig.direction = kSPI_MsbFirst;
g_masterConfig.outputMode = kSPI_SlaveSelectAsGpio;
g_masterConfig.pinMode = kSPI_PinModeNormal;
phbalReg_SpiInit();
#ifdef PHDRIVER_KSDK_SPI_POLLING
/* Initialize the DSPI peripheral */
SPI_MasterInit(PHDRIVER_KSDK_SPI_MASTER, &g_masterConfig, CLOCK_GetFreq(PHDRIVER_KSDK_SPI_CLK_SRC));
#else
SPI_RTOS_Init(&g_masterHandle, PHDRIVER_KSDK_SPI_MASTER, &g_masterConfig, CLOCK_GetFreq(PHDRIVER_KSDK_SPI_CLK_SRC));
#endif
return PH_DRIVER_SUCCESS;
}
static void phbalReg_SpiInit(void)
{
port_pin_config_t pinConfig =
{
.pullSelect = kPORT_PullDisable,
.slewRate = kPORT_FastSlewRate,
.passiveFilterEnable = kPORT_PassiveFilterDisable,
.driveStrength = kPORT_HighDriveStrength,
.mux = kPORT_MuxAsGpio,
};
/* SPI Configuration */
NVIC_SetPriority(PHDRIVER_KSDK_SPI_IRQ, DSPI_IRQ_PRIORITY);
/* Configure SSP pins (SCK, MOSI and MISO) */
pinConfig.pullSelect = kPORT_PullDisable;
pinConfig.mux = kPORT_MuxAlt2;
CLOCK_EnableClock(ENABLE_PORT_SSP_1);
PORT_SetPinConfig(PORT_SSP_1, FIRST_PINNUM_SSP, &pinConfig);
CLOCK_EnableClock(ENABLE_PORT_SSP_2);
PORT_SetPinConfig(PORT_SSP_2, SECOND_PINNUM_SSP, &pinConfig);
CLOCK_EnableClock(ENABLE_PORT_SSP_3);
PORT_SetPinConfig(PORT_SSP_3, THIRD_PINNUM_SSP, &pinConfig);
}
I tested another board, and NfcrdlibEx4_MIFAREClassic example is running correctly. So, I'm guessing that it may be some PN5190 EEPROM data misconfiguration? Is there any command to load/reset EEPROM data to factory defaults?
Meanwhile, I purchased PNEV5190BP and I'm trying these configurations:
I'll come back with some results.
Hi Abacus,
I would suggest you pull up the SPI signals on K32 side.
NFC cockpit tool can load/save EEPROM
Hi Daniel
I would suggest you pull up the SPI signals on K32 side.
I'll try that, but it does not seem an issue related to K32.
I managed to connect my PN5190 to the Evaluation Board (R5 and R7 shorted, R6 open).
First I got this warning, so I updated the FW to r2.F7 through Secure Upgrade.
I loaded default EEPROM data and I'm able to perform some operations, but once I hit "Rf Field On", the Evaluation Board and the Cockpit application, both become unresponsive. I need to power cycle to recover. Here's the output of Log Monitor:
[2023.11.24 11:21:20]:DEBUG:UcBalVComBalDelegate:TX [008]: 7F 07 00 04 00 00 01 00
[2023.11.24 11:21:20]:DEBUG:UcBalVComBalDelegate:RX [009]: FF 07 00 02 00 E4 FF FF FF
[2023.11.24 11:21:20]:INFO:EEPROMService_PN5190:Read from EE address:0x0000. Value=0xE4
[2023.11.24 11:21:22]:INFO:RFProtocolTuningService_PN5190:Load protocol: RM_A_106
[2023.11.24 11:21:22]:DEBUG:UcBalVComBalDelegate:TX [006]: 7F 0D 00 02 00 80
[2023.11.24 11:21:22]:DEBUG:UcBalVComBalDelegate:RX [009]: FF 0D 00 01 00 FF FF FF FF
[2023.11.24 11:21:22]:INFO:TypeACardViewModel:RM_A_106 Protocol loaded successfully.
[2023.11.24 11:21:25]:INFO:RfFieldControlService:RF On
[2023.11.24 11:21:25]:DEBUG:UcBalVComBalDelegate:TX [005]: 7F 10 00 01 00
[2023.11.24 11:21:26]:ERROR:App:Internal Error occured "The operation has timed out." in System
My PN5190 power configuration is the same as the default from the Evaluation Kit, so I believe default EEPROM data should be valid.
What else can I debug?