Question:How can i use the ANT7-T-M24SR64 on RaspberryPi 4B

[hentaikishi]

Hey i am Kishi(please forgive my poor English and my noob coding) Use i2c connect to ANT7-T-M24SR64,but RaspberryPi terminal comment can find the ANT7-T-M24SR64(SDA on pin 9,SCL on pin 10)

2.i use the library ,i try some method ,but it will be error I want to know how to fix this Thank you for your explanations.

[whaleygeek]

Hi, your English is good, I can understand you!

You need to build the .so file, as it is a binary file that is not cached in the github repo

cd python_proto/ci2c ./build

You might also discover that the gpio.c in this project is very old (7 years old) and won't detect the new memory addresses of the up to date Raspberry Pi computers.

There is a more up to date version of gpio.c in this repository: https://github.com/whaleygeek/SL030/tree/master/src/rfid/ci2c

The updated gpio.c correctly reads the GPIO PERIPHERAL_BASE from the device tree, and uses the correct address for the GPIO block based on the value that is returned, which makes it compatible with all Raspberry Pi's.

If you have problems copying over the gpio from the other project, please reply to this github ticket, I still have my M24SR boards here, and I could fix it and re-test it for you.

The ANT7-T-M24SR64 looks like a good board. I used the M24SR development kit panels (reference designs) for my project, which was used by @godley to build this project: https://www.youtube.com/watch?v=UkEVSy_CU7s

David.

[whaleygeek]

Can I also suggest that you check your wiring - the M24SR64 is supposed to report itself as address 0xAC (which would be listed in i2cdetect as 0x56 because it will be shifted right by 1 bit in i2cdetect) - but your screen shot above shows address 0x2d.

If you unplug the device and run i2cdetect again, does device address 2d still respond? You might have your wiring wrong, and something else connected to the i2c bus integral to the raspberry pi is responding.

See the data sheet here...

[whaleygeek]

My library also uses open-drain method of communicating, so you will need to add two pull-up resistors...

[whaleygeek]

Reference information (for whaleygeek) in case we need it:

The full data sheet for the chip is here: https://www.st.com/resource/en/datasheet/m24sr64-y.pdf

The full data sheet for the board is here: https://www.mouser.co.uk/datasheet/2/389/ant7-t-m24sr64-1848016.pdf

Mouser product page here: https://www.mouser.co.uk/ProductDetail/STMicroelectronics/ANT7-T-M24SR64/?qs=kHy2Dt%2FAQztZ1ixzDI3IkA%3D%3D

Note that there is an alternative ANT7-T-ST25DV04K that uses a different (Incompatible) chip.

[hentaikishi]

Hi, your English is good, I can understand you!

You need to build the .so file, as it is a binary file that is not cached in the github repo

cd python_proto/ci2c ./build

You might also discover that the gpio.c in this project is very old (7 years old) and won't detect the new memory addresses of the up to date Raspberry Pi computers.

There is a more up to date version of gpio.c in this repository: https://github.com/whaleygeek/SL030/tree/master/src/rfid/ci2c

The updated gpio.c correctly reads the GPIO PERIPHERAL_BASE from the device tree, and uses the correct address for the GPIO block based on the value that is returned, which makes it compatible with all Raspberry Pi's.

If you have problems copying over the gpio from the other project, please reply to this github ticket, I still have my M24SR boards here, and I could fix it and re-test it for you.

The ANT7-T-M24SR64 looks like a good board. I used the M24SR development kit panels (reference designs) for my project, which was used by @Godley to build this project: https://www.youtube.com/watch?v=UkEVSy_CU7s

David.

Sorry for the delay in responding to you Thank you for your explanations. terimal comment is working ,but sorry i don't know how to build pull-up resisor and i search how to do it ,but can't find the currect address

[whaleygeek]

On my original M24SR board, I used 4K7 resistors, but you can use most values and they will work.

[whaleygeek]

They are pull-up resistors, so one end goes to the positive supply (VCC) the other end goes to the pin (SDA or SCL). This is so that when the raspberry pi code drives it hard low (0V) the chip sees a logic 0, but when the raspberry pi sets the pin as an input, it floats high (pulled up by the pull-up resistor) to a logic 1.

[whaleygeek]

Also, this code is currently configured to use SCL/SDA on GPIO2 and GPIO3 of the Raspberry Pi (pins 3 and 5 of the 40-way edge connector)

Please check your wiring matches this (or you can change these two values in the code and re-run the ./build script to re-configure it) - although your wiring photograph seems to show them connected to the low numbered pins anyway??

[hentaikishi]

Thanks for your explanation about pull-up resistors !!! i got it!!! Here’s my circuit diagram Before the yesterday ,I wrote the wrong word on the paper The correct pins are SCL on Pin5 and SDA on Pin 3

I check on the terminal (i2cdetect -y 1) But the address on 0x2d

And I rebuild the i2c.so ,try m24sr.py

but it still can't works, How should i solve the error?

[whaleygeek]

Well done with your pullup resistors!

Can you send me the exact number printed on the chip on that board you are using? It is possible that the chip is different to what we think it is.

The '129' returned is hex 0x81, which is I2C_RESULT_E_NACK, this means the device did not respond to the query. I see that you changed the address to 0x2d in your build.

Do you have any type of diagnostics equipment such as an oscilloscope or a logic analyser, that could capture the state of the SCL and SDA pins for us?

Anyway, let me know the exact number of the chip, and I will check the datasheet to see if it is compatible with the chip that I originally wrote the driver for.

[hentaikishi]

Chip number is 24S64YA I can try borrow oscilloscope from school tomorrow. Thank you, I really appreciate your help.

[whaleygeek]

Here is the manufacturers datasheet for that chip: https://www.st.com/resource/en/datasheet/m24sr64-y.pdf

It confirms that the I2C device address is 0xAC/0xAD (8 bit code), which if you shift that right by 1 bit to get the 7 bit address (as i2cdetect seems to use), that translates to 0x56, as below

1010 110x A C

x101 0110 5 6

So, I am still very suspicious that i2cdetect is detecting a device on address 0x2d, because the bit pattern is nothing like the 0x56 address that the device expects.

x010 1101 2 D

So, I still have a hunch that your device is not responding for some other reason, and you are getting a reply from some other device that is on that same I2C bus (perhaps something integral to the Raspberry Pi or any other attachments you have, such as a fan controller etc?)

I did a bit of a search and found this page: https://i2cdevices.org/addresses/0x2d

Could you remove the wires between the Raspberry Pi and your ANT7-T-M24SR64 board, and run the i2cdetect tool again, and see what it responds with? I just want to rule-out whether there is another device on the bus that is responding. Thanks!

[whaleygeek]

Okay, I think I understand what might be going wrong here with you circuit!

I have looked into some of the Fan HAT's and they seem to have an I2C PWM controller for the fan speed, and you have to install kernel drivers and things to get them to work. That means that your Fan-HAT probably has control over the i2c bus that is on GPIO2 and GPIO3, and thus our Python code will not share that i2c bus reliably.

However, the i2c driver built into my M24SR python code is a software driver, so if you choose two other unused GPIO pins on the 40 way connector, change the SDA and SCL constants from 2 and 3 to the numbers of the GPIO's that you use (the GPIO numbers, not the pin numbers on the connector), and rebuilt the library with ./build, hopefully it should work.

This then raises the question - why is your ANT7-T-M24SR64 board not responding to the i2cdetect command? Hmm, perhaps you still have a wiring problem? Are you powering it from the 3V3 of the raspberry Pi (it probably won't tolerate 5V and will probably damage the chip if you have supplied 5V to it)

So, I think the first thing for you to do, still, is to remove your ANT7-T-M24SR connections and run i2cdetect to see if you still get a 2d address response, to prove that it is something on your fan controller that is responding to address 2d.

Let me know how you get on.

[whaleygeek]

The data sheet for the chip says it will tolerate 5.5V max, although you might not get the correct IO operation if you power it from 5V, as the logic levels won't match the expected voltages for the SCL and SDA pins (as the logic level on the Raspberry Pi is 3.3V).

Do check your wiring again, and if in doubt, put a multi-meter between the GND and VCC pins on your ANT7-T-M24SR64 board and check that it really is 3.3V.

[bansalpratik0]

Hey all! Thanks for such a detailed thread. I am running into a similar issue. I had the ANT M24Sr chip working just fine on my pi, however, now I am unable to get the pi to recognize the device. Shows up as 2d on my end as well. I have checked my pullup resistor circuit, made a new circuit with new components, used a different pi and a different ANT-M24SR chip - however no luck. I initially used 4.7k ohm resistors and have now gone up to 10k as well in an effort to see this work again - no luck.

Any help is appreciated.

Thanks!

[whaleygeek]

Hmm, should work ok like that. If it was working and now doesn't, what did you change?

My driver uses a soft i2c driver, so make sure the pi i2c is turned off in the raspiconfig.

I haven't tried the code on a later pi or later os, perhaps it is an incompatibility issue with later os versions?

[bansalpratik0]

Thanks for the reply! I was running into an issue of switching between i2c and RF mode. A simple fix was to control power via a regular GPIO and set to high/low. I think that was the downfall of my NFC communication. I have tried cycling raspi-config settings as well and taken out the GPIO control from my script. Currently, the m24sr is connected to 3.3V output on the pi.

I went ahead and tried using a X-Nucleo-NFC01A1 m24sr as well (these have pullups already) and that gave same results. I am now leaning towards an issue on the GPIO on my pi. Not sure about incompatibility as I had the system working for a few months and have not updated the Pi

[whaleygeek]

Ok, interesting. The m24sr has a token that switches between the rf and i2c side. If your token isn't well managed, you can end up with the rf side being always enabled and the pi being locked out. The project that I built this for was connected to an adafruit Gemma that power cycled on each rf use, so it naturally released the token. You might need to read the appnote and beef up the token handling.

This was the project that I wrote this code for, FYI...

https://blog.adafruit.com/2015/06/17/circuits-with-charlotte-light-up-nfc-bracelet/

[whaleygeek]

This is the main appnote for the chip... https://www.st.com/resource/en/application_note/an4420-m24sr-programmers-application-note-based-on-m24srdiscovery-firmware-stmicroelectronics.pdf

There is another note somewhere that has example message sequences in the appendix, that I used to work out the NDEF record handling.

[bansalpratik0]

Thanks for the reply! I was able to get the i2c working. There was an issue on gpio setup at boot. Is there a way to clear EEPROM memory on the m24sr using i2c?

[whaleygeek]

Glad you got it working!

You probably need to use the NDEF write command, to write an empty record. One of the appnotes from ST has a load of sample message sequences in it, I used that when first developing the code.