>
> &sixtron_spi {
> status = "okay";
> cs-gpios = <&sixtron_connector ADC1 GPIO_ACTIVE_LOW>;
>
> nfc: st25r95@1 {
> compatible = "st,st25r95";
> spi-max-frequency = <2000000>;
> reg = <1>;
> wkup-gpios = <&sixtron_connector DAC GPIO_ACTIVE_LOW>;
> };
> };
>
> ```
> **Fichier CMakeLists.txt n'a pas été modifié, mais voici son contenu**
>
> ```auto
> cmake_minimum_required(VERSION 3.20.0)
> find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})
> project(st25r95)
>
> FILE(GLOB app_sources src/main.c)
> target_sources(app PRIVATE ${app_sources})
>
> ```
> **Ligne de commande utilisée pour la compilation**
>
> `west build -p always -b zest_core_mtxdot`
Nicolas
---
### Author:  [@Sokario](https://forum.6tron.io/u/Sokario)
#### Post date: [Mars 25, 2025, 9:36 UTC](https://forum.6tron.io/t/probleme-avec-le-st25r95/50/4 "2025-03-25T09:36:18Z")
Bonjour Nicolas,
Je n’ai pas réussi à reproduire le problème exact, cependant, j’ai pu remarquer quelques erreurs :
- `nfc: st25r95@1` devrait être `nfc: st25r95@0` puisque `cs-gpios` n’a qu’un seul phandle (celui qui vous intéresse).
- par conséquent `reg = <1>;` devrait aussi être `reg = <0>;`
Par ailleurs, peut-être que le `main.c` de votre application ne récupère pas correctement le device en question.
Est-ce que le device est récupéré avec la ligne suivante ?
`static const struct device *nfc_dev = DEVICE_DT_GET(DT_NODELABEL(nfc));`
J’espère que cela pourra régler le problème, n’hésité pas à revenir vers nous si cela ne fonctionne toujours pas.
Logan Saint-Germain
---
### Author:  [@Nicolas](https://forum.6tron.io/u/Nicolas)
#### Post date: [Mars 26, 2025, 12:50 UTC](https://forum.6tron.io/t/probleme-avec-le-st25r95/50/5 "2025-03-26T12:50:18Z")
Bonjour,
J’ai réussi à compiler et flasher, mais je ne comprends pas pourquoi le driver est un « dummy ». S’il s’agit vraiment d’un « dummy », que dois-je faire pour faire fonctionner le NFC ?
Nicolas
---
### Author:  [@Sokario](https://forum.6tron.io/u/Sokario)
#### Post date: [Mars 26, 2025, 3:04 UTC](https://forum.6tron.io/t/probleme-avec-le-st25r95/50/6 "2025-03-26T15:04:41Z")
Bonjour,
Le driver actuel, du **st25r95** est bel et bien un `dummy` mais permet de valider la présence du composant sur la carte.
Il vous faut donc, pour faire fonctionner le NFC, écrire le driver zephyr correspondant. Vous pouvez reprendre le dummy driver actuel et y ajouter l’API avec les commandes I2C nécessaire ou repartir de zéro.
La datasheet du **st25r95** est disponible [ici](https://www.st.com/en/nfc/st25r95.html#documentation).
Je serai disponible si un problème survient lors du développement du driver.
Logan Saint-Germain
---
### Author:  [@Nicolas](https://forum.6tron.io/u/Nicolas)
#### Post date: [Avril 2, 2025, 12:35 UTC](https://forum.6tron.io/t/probleme-avec-le-st25r95/50/7 "2025-04-02T12:35:28Z")
J’ai réussi à compiler et à flasher le code, mais une erreur 0x83 (« Invalid protocol ») est apparue. Après quelques modifications du pilote, nous avons réussi à faire fonctionner le NFC et à obtenir l’UID des badges scannés. Cependant, pour poursuivre le développement du pilote, nous aimerions comprendre à quoi correspondent les deux dernières fonctions, qui sont vides : « `st25r95_attr_set` » et « `st25r95_channel_get` ». De plus, nous souhaiterions savoir comment ajouter le `irq_out` dans le fichier `app.overlay` afin de pouvoir récupérer l’UID correctement.
[Le driver modifié](https://gitlab.ciel-kastler.fr/nic.schmauch/zephyr_st-st25rg95)
---
### Author:  [@Sokario](https://forum.6tron.io/u/Sokario)
#### Post date: [Avril 2, 2025, 1:16 UTC](https://forum.6tron.io/t/probleme-avec-le-st25r95/50/8 "2025-04-02T13:16:17Z")
Bonjour,
- La commande `st25rg95_attr_set` n’est pas nécessaire dans votre développement.
- La seconde commande est lié au fonctionnement de Zephyr pour la récupération de donnée des composants suivant l’API **SENSOR**. Pour comprendre le fonctionnement complet, je vous propose de lire la [documentation](https://docs.zephyrproject.org/4.0.0/hardware/peripherals/sensor/index.html#implementing-sensor-drivers) Zephyr. Pour faire simple les **SENSORS** fonctionnement en deux étapes :
- Tout d’abord, il faut « échantillonner » et donc utiliser la fonction `sensor_sample_fetch(dev)` qui dans le cas du st25r95 est redirigé vers `st25r95_sample_fetch(dev)`. Cette fonction se charge de communiquer avec le capteur et d’enregistrer les données de la réponse du capteur dans la structure **st25r95\_data**.
- Une fois l’échantillonnage terminé, il est alors possible de demander au pilote une valeur issue de l’étape précédente : `sensor_channel_get(dev, channel, &value)` =\> `st25r95_channel_get(...)`. Cette fonction permet de retourner dans la variable **value** la valeur qui correspond au channel demandé. Dans votre cas, le channel `SENSOR_CHAN_ALL` pourrait tout à fait convenir. La liste des channels déjà supportée sur Zephyr est disponible [ici](https://docs.zephyrproject.org/4.0.0/doxygen/html/group __sensor__ interface.html#gaaa1b502bc029b10d7b23b0a25ef4e934). Le pilote doit donc retourner la valeur demander seulement dans le cas où le bon channel est demandé.
Pour ce qui est de rajouter des propriétés au pilote, il faut alors modifier le bindings la documentation zephyr se trouve [ici](https://docs.zephyrproject.org/4.0.0/build/dts/bindings-syntax.html#id4). Il faut donc rajouter les lignes suivante au fichier `st,st25r95.yaml`:
```auto
irq-gpios:
type: phandle-array
description: Configures ST25R95 interrupt signal.
```
Ce faisant, vous pourrez ensuite ajouter le phandle correspondant à votre signal d’interruption.
```auto
nfc: st25r95@1 {
compatible = "st,st25r95";
spi-max-frequency = <2000000>;
reg = <1>;
wkup-gpios = <&sixtron_connector DAC GPIO_ACTIVE_LOW>;
irq-gpios = <&sixtron_connector DIO3 GPIO_ACTIVE_LOW>;
};
```
Logan Saint-Germain