Interfacing X-NUCLEO-NFC05A1 with BBBWL using RFAL v1.3.0

[Ali Imran Najmi]

Posted on April 18, 2018 at 14:28

hi,

I am working withX-NUCLEO-NFC05A1 expansion board and connecting it to BBBWL and using the 'STSW-ST25R009 Linux® driver'& UM2375 User manual.

In BBBWL

- SPI port used is SPI1, detected as /dev/spidev1.0

changed the pltf_spi.c to reflect the change

/* ST25R3911XX is connected with Linux host's SPI port /dev/spidev1.0 */

static const char *device = '/dev/spidev1.0'; - Interrupt pin is GPIO115 - 115

changed pltf_gpio.h to reflect the change

/* GPIO pin no. 7 is used as interrupt line to receive interrupts from ST25R3911X.

* To use another pin as interrupt line please change the below definition. */ #define PLTF_GPIO_INTR_PIN 115 I get the below error please suggest

~/rfal_v1.3.0/build# ./applications/nfcPoller

Error: assigning high priority to polling thread

Note: this post was migrated and contained many threaded conversations, some content may be missing.

[Ulysses HERNIOSUS]

Posted on April 23, 2018 at 10:53

Hi Ali,

not sure about this one:

The offending code is in pltf_gpio.c:

params.sched_priority = sched_get_priority_max(SCHED_FIFO);
 ret = pthread_setschedparam(intr_thread, SCHED_FIFO, &params);
 if (ret) {
 printf('Error: assigning high priority to polling thread
');
 return ERR_IO;
 }�?�?�?�?�?�?

According to documentation e.g.

http://man7.org/linux/man-pages/man7/sched.7.html

it should be doneexactly this way. You may want to look at the documentation of your Linux system/kernel to see why this is failing.

Please try printing the ret variable by e.g. changing the printf to :

printf('Error: assigning high priority to polling thread : %s
',strerror(ret));�?�?

Which Linux version are you running on the BBBWL?

Regards,Ulysses

[Ali Imran Najmi]

Posted on April 23, 2018 at 11:44

Ulysses

I am using Debian 9.3 on the BBWL,

I comment out the code for now, defined the LED Pin, it moves ahead but

still not able to make it work.

Looks the SPI communication isn't happening.

Ali

On Mon, Apr 23, 2018 at 2:23 PM Ulysses HERNIOSUS <

[Ulysses HERNIOSUS]

Posted on April 24, 2018 at 09:46

Hi Ali

I googled around and didn't find why the Linux APIs may be different on this Debian. When nothing is working then I guess you will need to attach a logic analyzer to see SPI + IRQ and analyze.

Regards, Ulysses.

[Ali Imran Najmi]

Posted on May 18, 2018 at 13:12

hi Ulysses,

I downloaded a lastest build of BBB and it fixed both the SPI communication and the priority issue. I am able to read the cards UID using the sample nfcpoller applicationuname -a

Linux test 4.9.82-ti-r102 &sharp1 SMP PREEMPT Thu Feb 22 01:16:12 UTC 2018 armv7l GNU/Linux

cat /proc/version

Linux version 4.9.82-ti-r102 (root@b2-am57xx-beagle-x15-2gb) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) &sharp1 SMP PREEMPT Thu Feb 22 01:16:12 UTC 2018

But got a new issue, stop getting interrupt after a while. if I reinit the  Do you have a updated rfal or sample which fixes this issue?

[Ulysses HERNIOSUS]

Posted on May 23, 2018 at 13:25

Hi Ali,

no this is the latest version. We have not observed such a fail up to now. What is the state of the INT pin when the issue happened?

Ulysses

[Ali Imran Najmi]

Posted on May 23, 2018 at 14:05

hi Ulusses,

Thanks for your response. the INT pin stays low, If I reinitialize the lib or restart the sample app it starts working again. 

If I dont have the LED's how do I ignore them in RFAL? the below are defined in RFAL it doesn't have the option of not defining them.

&sharpdefine LED_NFCA_PIN &sharpdefine LED_NFCB_PIN &sharpdefine LED_NFCF_PIN &sharpdefine LED_NFCV_PIN &sharpdefine LED_AP2P_PIN &sharpdefine LED_NFCA_PORT 0&sharpdefine LED_NFCB_PORT 0&sharpdefine LED_NFCF_PORT 0&sharpdefine LED_NFCV_PORT 0&sharpdefine LED_FIELD_Pin &sharpdefine LED_FIELD_GPIO_Port 0

[Ulysses HERNIOSUS · Accepted solution]

Posted on May 25, 2018 at 11:02

Hi Ali,

• regarding the LEDs: If you don't have any LEDs at all, then maybe you can just define the platformLedOn/ledOff macros empty. Alternative could be to have some global variable which denot the LED state and let the LED_....PIN point to these variables. Then you can 'see' the led state while debugging.
• regarding the interrupt issue: I guess you will need to attach a logic analyzer and analyze the traces. There are a number of PC based ones like Digiview, Saleae and others. If you don't spot the issue then I can also have a look and give you hints.

Ulysses.

[Ali Imran Najmi]

Posted on May 25, 2018 at 11:26

hi Ulysses,

regarding the LEDs:

I will setup the LED's with variables thanks,

regarding the interrupt issue:

I don't have the logic analyser handy will take time till I get one. It would be a good Idea for you to check as well.

Kindly keep me posted, I will do keep you posted on our findings

- Ali