cancel
Showing results for 
Search instead for 
Did you mean: 

ST25 NAK after 3 commands

robertp
Associate II

Hello,

I have a really weird behaviour for my chip which I can't really figure out. Basically, I am using only the commands from the ST25DV library (st25dv discovery board).

After 2 function calls (for example present password and disable RF) the subsequent calls get all not acknowledged.

If I reverse the order of the instructions then those instructions will get executed correctly and the other ones won't.

Could someone provide a hint on what could go wrong?

Kind Regards

This discussion has been locked for participation. If you have a question, please start a new topic in order to ask your question
1 ACCEPTED SOLUTION

Accepted Solutions
Rene Lenerve
ST Employee

Hi Robertp,

on my side I didn't encountered any issue using this project on a ST25DV-DISCOVERY.

It might be useful if you could spy the I²C bus or capture with a scope SCL and SDA signals, to try to understand why the tag "NACK" commands.

I wish you good luck for your exam.

Kind Regards.

View solution in original post

7 REPLIES 7
Rene Lenerve
ST Employee

Hi @robertp,

Can you share some of your code that you are using to help reproduce this bad behavior. You will also find some examples around RF Off or RF Sleep in the ST25DV-DISCOVERY software package which may help you in using these functions.

Kind regards.

Hello, sorry for the late reply. I've been dealing with other projects.

I would be glad to share my code:

 

robertp_0-1697563758238.png

Perhaps I should mention that I've been wrapping the SD25DV calls with my own I2C LL implementation. However, I didn't have different results with the HAL implementation either, and regarding the protocol the data on the wires seems to be alright.

I am suspecting I am using the User Layer of the ST25DV in a wrong way. Can you confirm that ?

Thank you and kind regards!

Robert

Rene Lenerve
ST Employee

Hi @robertp,

First comment, could you please use code sample tag for the shared code it will ease the exchange.

Second comment, be careful converting boolean to integer, false and true could be defined as

 

#define false 0
#define true !false

 

and in that case !0 isn't 1.

For ISO C99 defined value of false and true are 0 and 1 (but in certain environment it could be something else)

Third comment, I'm sure you're doing correctly but in your capture ResetRFDisable is commented due to a missing comment tag */

From what you've shared I don't see anything wrong, be careful to have correctly set nfc_io structure for

ST25DV_RegisterBusIO

 

  nfc_io.Init         = BSP_I2C2_Init; //to adapt in your case
  nfc_io.DeInit       = BSP_I2C2_DeInit;
  nfc_io.IsReady      = BSP_I2C2_IsReady;
  nfc_io.Read         = BSP_I2C2_ReadReg16;
  nfc_io.Write        = (ST25DV_Write_Func)BSP_I2C2_WriteReg16;
  nfc_io.GetTick      = BSP_GetTick;

 

Do you have also this issue when you compile and run the ST25DV-DISCOVERY demo?

If you still have the issue, maybe you could share more of your project to determine where the issue is.

Kind Regards.

robertp
Associate II

Hi @Rene Lenerve .

Thank you very much for your reply. I appreciate your comments and I will follow them in the future.

Regarding the demo project for the Discovery Board, I had problems finding a working example that will just work straight away after I import the project in the STM32CubeIDE. Perhaps you could provide a project that is intended to work for the CubeIDE and only the CubeIDE- doesn't have to be the same as the demo project, a simplified sequence of commands would suffice. And it would be perfect if it could be using the LL drivers.

Maybe it would be a good starting point if you could provide this minimal working example that just executes a sequence of commands, as I have no clue what to watch next in order to find the problem.

 

Thank you and kind regards!

Robert

Rene Lenerve
ST Employee

Hi robertp,

I have built a simple project to start communication with the ST25DV on the ST25DV-DISCOVERY board with STM32CubeIDE. Started from scratch with cubeMX to generate just sufficient sources in Low Level drivers to initialized I²C and a GPIO for the Led.

Give it a try to see if it is working also on your side.

The low level I²C communication are given as is, not greatly tested, patched from various examples (no ready to use examples for that) and HAL I²C drivers (but for the example it is ok).

The test is just sending some commands and blink LD2.

Hope this helps you use our drivers in your environment.

Kind Regards.

 

Hi Rene,

I'm so sorry, but unfortunately your example project still doesn't provide the solution. After the first commands the next ones still don't get acknowledged. I have currently no clue what else to try. However, I am currently away for 2 more weeks because I'm learning for an exam. I will need to try something else. As far as I remember the original demo application worked as intended (thus using the HAL). I tried replacing the wrapper functions to point to the HAL implementation instead some time ago, but still without success. I will try using the HAL functions again, perhaps I accidentaly did something wrong.

However, I wonder why the problem would occur with the LL drivers.

 

I'll write more to this topic in few weeks.

Kind regards

Rene Lenerve
ST Employee

Hi Robertp,

on my side I didn't encountered any issue using this project on a ST25DV-DISCOVERY.

It might be useful if you could spy the I²C bus or capture with a scope SCL and SDA signals, to try to understand why the tag "NACK" commands.

I wish you good luck for your exam.

Kind Regards.