declaration of BSP_SPI1_IRQ_Callback() in FreeRTOS_polling

[DSai.1]

about declaration of BSP_SPI1_IRQ_Callback() in ST25NFC_Embedded_Lib_ST25R3916_1.4.0\Projects\STM32L476RG-Nucleo\Applications\X-NUCLEO-NFC06A1\FreeRTOS_polling

Dear Sir,

I am check the process flow of sample program which use FreeTROS.

I found that the function BSP_SPI1_IRQ_Callback() is declared in two place,

one is in nucleo_l476rg_bus.c, another is in plf_adaptation.c .

Could you tell me which one is used in this demo sample?

Also, in this sample code, st25r3916Isr() is called in two different place.

one is in

----------------------------------------

void nfcIsrTaskRunner(void *argument)

{

 /* Infinite loop */

 for(;;)

 {

   ulTaskNotifyTake( pdTRUE, portMAX_DELAY );       /* Check if IRQ happen execute immediately, otherwise other execute Task meanwhile */

   st25r3916Isr();                     /* ISR called from main task avoid calling vTaskSuspendAll from ISR (SPI) - NFC IRQ pin is anyhow checked */

   xSemaphoreGive(platformSem);

 }

}

-------------------------------------------------------

another is in

--------------------------------------

__weak void BSP_SPI1_IRQ_Callback(void)

{

 /* Prevent unused argument(s) compilation warning */

  

 /* This function should be implemented by the user application.

  * It is called into this driver when an event from ST25R3916 is triggered. 

  */

 st25r3916Isr();

}

---------------------------------------

Are there two manners used in this demo? What are the main differences for them?

Best regards

Dai Sai

[Brian TIDAL]

Hi,

ST25R_SELFTEST and ST25R_SELFTEST_TIMER are adding extra checks during st25r3916Initialize. Thus the return code might be different once those 2 defines are enabled.

Rgds

BT

[DSai.1]

Dear Brian,

thank you very much for your great help.

According to your information, we found some bug for IRQ process. Now both return code of rfalinitialize() and rfalFieldOnandStartGT() are ERR_NONE.

But it seems that the rfal_demoCycle() does not work still. when run rfal_demoCycle(), there

is no IRQ signal any. Would you like to show me the demoCycle that I should refer to?

best regards

Dai Sai

[Brian TIDAL]

Hi,

the demoCycle should be the one provided with the freeRTOS demo. Most of the adaptations should be done inside platform.h (for example just define the platformLog macro as an empty macro if no logging rather than commenting demoCycle or define platformLog to use to your own logging mechanism, define plaformDelay to use tx_thread_sleep, etc. ). So, demoCycle should ne be modified or modification should limited to comment the user button management (stubbing BSP_PB_GetState would avoid to change the demoCycle code). If only ISO15693 support is needed for your application, you can set RFAL_FEATURE_NFCA, RFAL_FEATURE_NFCB and RFAL_FEATURE_NFCF to false in platform.h and keep only RFAL_FEATURE_NFCV to true (this avoid again to modify the demoCycle).

I guess tx_semaphore_get is blocking (no timeout) in ddi_Rfal_Tag_Rx_Thread:

rfal_demoCycle();
tx_semaphore_get((TX_SEMAPHORE_PTR)&g_pRfalSemaSt25r3916IRQ);

For debug purpose, I would propose to run rfal_demoCycle in a non blocking manner as a dense loop. Once the demoCycle is able to properly detect a tag, synchronisation/semaphore/time saving can be added in a second step.

Also, I suggest to connect a logic analyzer on SPI (CLK/MOSI/MISO/CS) + IRQ to debug in case something is not working on NFC.

Rgds

BT

[DSai.1]

Dear Brian,

thank you very much for your information.

I used a ISO15693 tag for test. When I put a tag on the antena, and then start to run

demoCycly(), I can get the UID successfully.

But there is a problem.

When I run demoCycly() without existence of the tag for a while,

the IQR signal disappered, Even I put the tag on the antena, there is no reaction,

no IQR signal, no UID can be obtained.

When running demoCycly() with existence of the tag from starting, the UID can be

obtained, but about 10 to 20 mintues passed, UID can not be obtained again. In this case,

IQR signal disappeared, and RF carrier is ON forever..

I checked the program in debug mode, and found

if (rfalNfcIsDevActivated(rfalNfcGetState())) is not satified in rfal_demoCycle().

At this time, gNfcDev.state = RFAL_NFC_STATE_LISTEN_TECHDETECT.

In normal case, gNfcDev.state transit as followings

RFAL_NFC_STATE_POLL_TECHDETECT

RFAL_NFC_STATE_POLL_COLAVOIDANCE

RFAL_NFC_STATE_POLL_ACTIVATION

RFAL_NFC_STATE_ACTIVATED

attached file is my test code.

Would you like to give me some suggests for this issure?

It seems the goal is near?

best regards

Dai Sai

[DSai.1]

platform.h aslo here

[Brian TIDAL]

Hi,

"It seems the goal is near?" yes I believe so.

The RFAL_FEATURE_LISTEN_MODE (support for NFCA/NFCF card emulation) is set to true whereas NFCA and NFCF are disabled. I guess this is causing your issue. Would you please try to set RFAL_FEATURE_LISTEN_MODE to false?

Rgds

BT

[DSai.1]

Dear Brian,

I modified the platform and set only

#define RFAL_FEATURE_NFCV           true    /*!< Enable/Disable RFAL support for NFC-V (ISO15693)   

But same problem didi not changed. Were there such issues happened before?

best regards

Dai Sai

[Brian TIDAL]

Hi,

"Were there such issues happened before?": usual suspects are:

• stack overflow (stack size too small)
• deadlock (mutex, etc.)
• st25r3916interrupt.status (in case of platformProtectST25RIrqStatus implementation issue)

I would suggest to test that each threads are still alive. For example I would toggle a LED every second in the main thread, I would set a specific GPIO to High during the ISR thread processing, I would manually force the IRQ pin to high to check whether the ISR task is stuck (in that case make sure to disconnect the ST25R3916 IRQ from the MCU IRQ pin to avoid level conflict).

If the RTOS awareness debugging is available, I would check the stack size during run time, I would check the thread status, mutex/semaphore status.

I would also check possible failing case in ddi_rfal_IRQ_Protect that may return without calling hw_icoll_EnableVector(VECTOR_IRQ_GPIO0, false) and causing a wrong value of st25r3916interrupt.status.

Also, feel free to use a logic analyzer on SPI (CLK, MOSI, MISO, SS) + IRQ and to send me the trace when the system hangs (hopefully with part of the trace before the system hangs :-))

Rgds

BT

[DSai.1]

Dear Brian,

thank you very much for so helpful suggestions for this issue.

I confirmed that the demoCycle() is in loop with no-freezing.

I will check mutex and IRQ later.

Hope I can send you a good news next week.

This weekend, I will spend vacation on beach for relax.

Happy weekend.

Best Regards

Dai Sai

[DSai.1]

Dear Brian,

After a sunny weekend holiday in beach, I tried to solve the problem on this week.

Here is a good news! The demo program can read UID and single block correctly.

It is a great step for these porting days. Thank you so much for your great help!.

There is a issue I found this morning.

There is no problem to read one block with

err = rfalNfcvPollerReadSingleBlock(reqFlag, uid, blockNum, rxBuf, sizeof(rxBuf), &rcvLen);

and err is NON_ERROR(0).

But, when I try to read multiple blocks (2 blocks for test ) with

err = rfalNfcvPollerReadMultipleBlocks(reqFlag, uid, 0, blockNum, rxBuf, sizeof(rxBuf), &rcvLen);

and err is ERR_CRC(21).

In debug mode, I found the two blocks data in buffer rxBuf are correct, but return code is 21,

meaning CRC error.

Based on RFAL code, the above two function call the following function in RFAL driver.

rfalNfcvPollerTransceiveReq()

and

ret = rfalTransceiveBlockingTxRx( (uint8_t*)&req, (RFAL_NFCV_CMD_LEN + RFAL_NFCV_FLAG_LEN +(uint16_t)msgIt), rxBuf, rxBufLen, rcvLen, RFAL_TXRX_FLAGS_DEFAULT, (specialFrame ? RFAL_NFCV_FDT_EOF : RFAL_NFCV_FDT_MAX) );

Would you like to give me any hint for this CRC error issue?

Best regards

Dai Sai