whaleygeek/pi_m24sr

Asking for help!

Closed this issue · 11 comments

Hello David.(Please forgive my poor English :D)
I`m working with m24sr64 and Raspberry Pi, and I have been struggling with this for half a month, cause I`m a java programmer and i can not find java lib for m24sr64 and Raspberry Pi.
When i found your project, i fell very happy and decide to have a try with python.
But now i have problem with the i2c address:
I build i2c.so file following the command int the build file and run "sudo python m24sr.py".
But it seems there are no bytes writen to m24sr.
Here is the Screenshot:
image
And here is my i2c information:
image
image
I wonder if i select the wrong address?
Thank you very much!

Hello! And thanks for your question. Your English is great!

This is quite an old piece of software, and also the Raspberry Pi has moved forward a lot and introduced some changes that may cause problems here.

The m24sr software here uses a software based I2C driver - this was a choice I made because at the time I wrote this, hardware I2C required a bit of configuration that used to confuse users; however now with the latest OS hardware I2C is easy to turn on in the settings.

Because this is a software I2C driver, it drives GPIO lines directly, from C. In the early OS versions the hardware I2C was off by default.

So, to the solutions...

  1. To use this software driver, make sure you disable the hardware I2C in the Raspberry Pi configuration screen, so that it releases the GPIO pins for use by software.

  2. If you have a Pi2 Pi3 or Pi4, there were memory map changes to where the GPIO peripherals were located due to the change of chip, and the software driver here has not been updated to match those changes.

Fortunately, I use the same software driver on another proect and that has been kept up to date with memory map changes, you can get a the file here: https://github.com/whaleygeek/pyenergenie/blob/master/src/energenie/drv/gpio_rpi.c

So, turn off the hardware I2C in the Raspberry Pi config, and copy the gpio_rpi.c from the other project over the top of the gpio.c here, and rebuild the C and try again.

Please let me know if this works (or if you get the same or different effects).

I do still have a board here somewhere so if you are really stuck I may be able to connect it all together and try it myself. But I think these two solutions should fix the problem.

You may be interested to know that this Pi/Python software was a prototype that I built. The final version was written in Arduino CPP and was run on an Adafruit Gemma V1, and then used with NeoPixels and an Android app, by my friend @Godley to build a programmable bracelet. You can see the project video here: https://www.youtube.com/watch?v=UkEVSy_CU7s

David.

It works!
I copied the code in gpio_rpi.c to gpio.c and change conflicting tyoe "uint8_t" to "int", and rebuild the i2c.so, finally it works!(I forgot to turn off the i2c in config but it still works. )
Thanks for your help and patience!
But there is another question : when the program end with right data, I found that my android phone with ST25 dbg (ST offical APP) can not found the nfc tag. It has no effect when i turn off the i2c in config before running the program. It return to work only after i re-insert the nfc model. Is there anything i missed? Such as a command to open the RF function? Im searching the M24SR64 datasheet but have no idea till now. Thanks again! And I just looked your frind Charlottes video! That cool and interesting~! I wanna be a cool girl like her(〃ノωノ).
Finally, thank you for your help!

Hello - fantastic, glad it works, and thanks for letting me know!

Regarding the follow-on question, I assume you mean that once you have read the tag, you cannot interact with it again until you move the Android phone away and then bring it closer to the M24SR again?

It is possible that @Godley and I never needed to re-connect to a tag once it was written to, as the demo she was building only had to write to the tag from Android once in any transaction.

Charlotte might have some ideas, but it could be an Android issue rather than a tag issue (Although perhaps there is a open-tag/close-tag pair that we have not found).

Charlotte's project write-up:
https://www.element14.com/community/people/charlotte_godley/blog/2015/04/28/the-light-up-nfc-bracelet-project-step-1

https://www.element14.com/community/people/charlotte_godley/blog/2015/06/12/the-light-up-nfc-bracelet-project-stage-2

The step-2 link describes the Android app side.

However, I imagine that Charlotte and I never used it in a multi-transactional sense like this, and that you are trying something new with it.

I will check the datasheet for M24SR, but I remember that there was a more detailed AppNote we used that showed a number of sample transactions - let me see if I can find that for you.

David.

Ok, so the Application Note AN4433 from the chip manufacturer (ST Microelectronics) has detailed command traces, an this is what I used at the time we worked on the project to work out a sequence of commands to write NDEF records.

Here is a link to the PDF...

https://www.st.com/content/ccc/resource/technical/document/application_note/f4/ce/4c/0e/28/0d/4d/38/DM00105043.pdf/files/DM00105043.pdf/jcr:content/translations/en.DM00105043.pdf

There are some warnings on page 11 here:
M24SR memory cannot be accessed (read and write) through RF interface, if an
I2C session is opened.

– M24SR memory cannot be accessed (read and write) by default through I2C
interface, if an RF session is opened.

So I suspect the chip has an internal token/state it switches between I2C mode and RF mode, and you may need to send other commands to switch it between modes - i.e. once accessing via I2C, you may need to send a specific command to the chip to release the I2C token and allow the RF to operate again.

Read through that App note to see if you can find any details about mode switching, but let me know if you get stuck.

David.

P.S. @Godley was pleased that you called her a 'Cool Girl' :-)

Thank you verrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrry much for your reply!

I`m sorry i did not express clearly about the question but i think you provide the right advice. My m24sr64 is made as a pluggable module which is connect to the Raspberry Pi with pin header like this:
image

After running the python program on raspberry, the m24sr64 will not response the android app until I extract my module and re-connect it with Raspberry Pi.

Charlotte`s guide is very helpful for me! cause i`m also working on the Android App relative with Raspberry Pi.

And thank you for the datesheet, it`s very helpful! It even gives the CRC byte! I`ve download the PDF and i will struggle with the datasheet tomorrow morning! I will let you know the result!

And my little goal is to config wifi via nfc moudle and Android App and to know normal operation about Raspberry Pi I2C. It works now but i want fix the mode problem. Thank you for your driver, it really helps me a lot. I know nothing about hardware_(:з」∠)_

Nice to communicate with you and Charlotte, thank you very much!

P.S. Exactly I should say "cool and beautiful girl".('▽')I have to go to sleep and see you tomorrow!

Hi David, I found in another datasheet (the M24Sr64 datesheet) it`s said to open RF session I should send "a valid Select Application" command. I tried use Android to send "select NDEF application" command but it doesn`t work. And i didn`t find the "Select Application" command.

I will have another try tomorrow.

I have a hunch here. If you use the M24SR powered down (disconnected from Pi), because it uses energy harvesting from the RF to power the chip when in-range of the Android device, I suspect it automatically does a 'select RF' (so that it can work in a batteryless form factor).

However, once the board is powered by the Pi, I suspect it ends up automatically in I2C mode by default, thus confirming what you said earlier about 'it doesn't work when attached to pi'. Because the RF is not selected, it will not be possible to send it a command over the RF.

So, that makes sense.

You might be able to send it a deselect command from the I2C to release the token, which would then allow the RF to be selected.

AN4433...
Screen Shot 2019-11-19 at 17 45 14

M24SR datasheet...
Screen Shot 2019-11-19 at 17 49 03

So I think all you need to do is to make sure you send a DESELECT command from the I2C interface, which will put the chip into standby mode, and allow the RF interface to power via energy harvesting then claim the token.

Additionally, one of the GPIO pins on the M24SR can be configured to indicate if the RF mode is active or not, and this could be used by the Pi with an 'interrupt on pin change' so that when the RF is de-selected, the RF_ACTIVE line changes state, interrupts some script on your Pi to say that the Android has just accessed the memory, so that the Pi can then use the I2C mode to claim the token and read the EEPROM details previously written by the Android.

Hope this helps.

Hi david, thank you for your reply.

You are right, the deselect command is required. I realized that error occurs when i write a wifi configuration message on M24SR64 and the program exit halfway so the deselect command did not send. And my antenna is not very sensitive so I got the wrong result. I`m so sorry for that.

Thank you for your patience~! Have a good day~

And should I close the issue?

Great, glad it all works, well done! Yes, I'll close the issue, but please do report back when you have the whole system implemented, it would be good to see a demo. Also it would make a great write-up for the MagPi RaspberryPi community magazine https://magpi.raspberrypi.org/

You can read about the article submission process here and contact them via email/twitter etc.

https://magpi.raspberrypi.org/articles/write-magpi-magazine

Good luck with the rest of the project!

David