Errors while compiling the FW STSW-ST25R011 of the “ST25R3916 Discovery Kit ?.

[TDumb.1]

Dear STCommunity members,

I’d like to test the MB1414 (ST25R3916_Discovery_DB) using the I2C interface. So, besides changing the Hardware of the MB1414 (by changing J200, J201, J202, J203, J204 and J205) I also need to update the Firmware of the MB1396 (ST25_Discovery_Mboard) to implement this interface.

For a couple of days, I’ve been trying to compile the FW STSW-ST25R011 provided for the “ST25R3916 Discovery Kit�?, but unfortunately, without success. Probably I am committing a silly mistake since I am not really familiar with this environment.

I am using the Atolic TrueStudio V9.3 to compile it, but after using the Import Wizard to import the “Existing Projects into Workspace�? and “Build Project�? I am getting the following error/warnings (see details attached: “Build_Log_fatal_error.txt�?):

fatal error: stm32l4xx_hal.h: No such file or directory – despite the fact that its include folder is correctly added in the “include directories�? (see details attached: “Screenshot Path and Symbols .png�?).

Obs.: I also tried to compile it using the STM32Cube IDE V1.10 without success.

1- Could you please help me to compile this FW?

2- Could you please tell me which parameter in the FW should I change in order to set the I2C communication in place of the SPI?

Many thanks.

[Brian TIDAL]

Hi,

can you check that stm32l4xx_hal.h is actually physically in .\ST25R3916_DISCO_v1.2.0\Middlewares\ST\fw_3916\DISCO-STM32L4x6\Drivers\STM32L4xx_HAL_Driver\Inc?

Rgds

BT

[TDumb.1]

Dear Brian,

Thanks for replying to me.

Yes, it is physically in the mentioned subdirectory as you can see attached. in fact, even the IDE opens it when I click with the right button of the mouse on the #include stm32l4xx_hal.h and select "F3 - Open declaration".

Ps. I am using exactly the same file provided by ST available online (https://www.st.com/content/my_st_com/en/products/embedded-software/st25-nfc-rfid-software/stsw-st25r011.html)

Best Regards,

[Brian TIDAL]

Hi

Can you try to shorten the folder depth and the path length as I suspect a kind of MAX_PATH issue?

Rgds

BT

[TDumb.1]

Brian,

That's great!

The problem was exactly that. I created a workspace directly on C:\Project\.. so the compilation and debugging are working well!

Thank you!

Now,

Could you please tell me which parameter in the FW should I change in order to set the I2C communication with the daughter board (MB1414 - ST25R3916_Discovery_DB) in place of the SPI?

Kind Regards

[Ulysses HERNIOSUS]

Hi,

the software package is not ready out of the box to support I2C. Some files need to be adapted, I2C block in L4 activated, etc.

We have other software packages where the I2C is ready to be used (e.g. X-CUBE-NFC6 or the STSW-ST25R-LIB.

Do you have a specific need to use exactly this board or its FW? Its firmware has lots of overhead due to PC communication and also its display. In general the above two packets are much easier to understand and especially the STSW-ST25R-LIB makes also use of the latest RFAL with its new more high-level APIs.

Best Regards, Ulysses

[TDumb.1]

Hi Ulysses,

It's great to hear from you.

It is a pity! As the MB1414 (ST25R3916_Discovery_DB) has I2C and SPI access, I'd assumed that the firmware could be recompiled for I2C communication just by changing a #define RFAL_USE_I2C :(

Actually, I was expecting to use the Disco MB1396 to test and validate our cDB (custom daughterboard based on ST25R3916) in I2C mode.

Sorry for mixing up the topics but I will enjoy to explain our real problem. If you prefer, please let me know so I can open a new topic.

Our cDB board works nicely connected to the ST25R3916-DISCO via SPI. However, when connected via I2c to our STM8 motherboard (I2C_EN pulled to VDD_D) the cDB does not acknowledges the 50h address. It just behaves as if 50h were not the correct address.

We have checked with a logic analyzer and a scope. The ST25R3916 does not pull the SDA line.

We have made trials powering the ST25R3916 with 5V as well as 3,3V.

We cannot use ST RFAL firmware as it would not fit into the memory of the STM8L151 with 64k of memory, which a large part is used by our own control program. However, the solution is elsewhere.

Could you please give me some piece of advice?

Thank you.

Best regards

[Ulysses HERNIOSUS]

Hi,

it should work, for reference I am adding a shot from a working i2c. I assume you are using official samples, no samples marked as ES (Engineering samples) ?!

Best Regards, Ulysses

[TDumb.1]

Amazing, that will definitely help us.

Yes, they are official samples.

I will do some tests and i will come back to you guys.

Thank you

[Brian TIDAL]

Hi,

Address 50h is the 7-bit address of the device. Therefore the byte #1 of the I2C frame (I2C Address Field) has to be A0h (Write) or A1 (Read). Can you connect a logic analyzer and check that the I2C Address Field is correct?

By the way, the RFAL is scalable: in particular if only one technology is used (e.g. NFC-A), other technologies can be disabled and this significantly reduces the memory footprint.

Rgds

BT