Question about read ndef message

[Winterlx]

Hi david, it me, and im sorry to border you but i have meet this question for serval days.

I use the m24sr.py program to read ndef message from m24sr using Raspberry Pi, and sometimes it works smoothly.

But sometimes, I get a error when reading ndef message:


I found it has an error here:

And the result value is "129".

If you have any idea with this, please tell me. It will help me a lot.

Thank you very much!

[Winterlx]

And the correct NDEF message is here:

[whaleygeek]

Hello,

Looks like you are making good progress.

This is the M24SR device sending a NAK back

We would need to check the datasheet for the device to see under what circumstances it can reply to a byte with a NAK - some devices use NAK normally to mark the end of a data transfer, some use it as an indication that you have not completely followed the protocol for the command.

Is it possible that the device is just signalling that it is busy? If so, the usual fix would be to re-send the message again (e.g. your app might have a retry loop sending the command and reading the response up to some maximum such as 4 retries before really stopping.

But the datasheet should indicate the conditions under which a NAK is returned.

[whaleygeek]

I see it looks like the NAK is coming back on the first byte (the address byte). The way I2C works is that the data line will float high unless pulled down by the responding device, which creates a default NAK if no device is connected.

So seeing a NAK in the address byte response basically means that the device has not replied at all. It could be that there is a time restriction for the device to operate internally before it will validly reply again, or it could just be you have a bad connection somewhere and the address byte didn't get through.

Also check that the values of any I2C pullup resistors are correct, as that is critical for I2C to work correctly. I don't know if you are using one of the ST reference boards or if you have made a board yourself (can you share a picture yet??) but check what value of resistor is fitted to the SCL and SDA lines.

[whaleygeek]

These were the boards we used on our project... https://www.st.com/en/evaluation-tools/matrix-m24sr.html there are many different samples and you snap out the one you want to try... I used to buy them from Farnell element 14, but I don't think they stock them any more?

[MattBlanco]

@whaleygeek I tried adding 4.7k pull-up resistors to my SDA and SCL but I'm still getting the same error code winter is getting.

[whaleygeek]

@MattBlanco Note that the M24SR has a lock token, if you write to it from the RF interface, the host I2C interface is locked out. Make sure you power cycle the board after writing from RF before testing the I2C.

Also, what version of Pi are you using? They keep moving the I2C peripheral memory address around, and the gpio.c in this code was written before I updated it to self discover from the device tree. Look at the gpio_rpi.c on this project to see how I fixed that:

https://github.com/whaleygeek/pyenergenie/blob/master/src/energenie/drv/gpio_rpi.c#L56

You could try just overlaying that file here and rebuilding, as the gpio.c in this repo looks to not have the changes for the new Pi memory map that reads the address from the device tree file.. https://github.com/whaleygeek/pi_m24sr/blob/master/python_proto/ci2c/gpio.c#L56

There is now an official I2C BCM C driver you could use instead - there wasn't one around when I first wrote this project, so I had to roll my own at the time.

[MattBlanco]

I'm not writing to it with RF, I'm simply running the m24sr.py file and getting the errors from above. And I'm using the raspberry pi 4 model B. I had already done the overlay for the gpio.c, which seemed to fix the issue I had before of the program not writing anything to the M24SR, but I still get the issue from above. It seems to happen at different points each time I try to run the program or it finishes with no errors, so I'm not sure what the issue could still be. It's obviously not stable enough to use with my codebase.

[whaleygeek]

The clue is in the name actually (python_proto). This repo never aimed to provide production ready code. The Python was a stepping stone to the arduino code (as the Pi was easier to get visibility of everything interactively at the Python REPL prompt).

The arduino code itself was only ever written as a bit of demo code that had to work once, for a demo.

If you are looking for production code, this isn't it. Look in the ST cube driver library, as the M24SR NDEF tag board was designed to work with that whole ecosystem. Although, do check their licence, it may require you to use the driver on a ST core only. https://www.st.com/en/ecosystems/stm32cube.html

If you could attach a bus analyser or scope and send me a trace of a working and a non-working transaction, I may be able to be of more help.