-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Connection lost during NFC Memory Dump #9
Comments
If the one sensor is unreliable, it might be a dead battery. RF430 devices can work without a battery, but they aren't very reliable about it, especially on a dead one. Memory reads are done in transactions of 8 bytes, which is the smallest supported by the TAL without firmware patching. A better method might be some sort of a queue, so that you could break away from the tag and fill in the blanks on a later read. |
Thank you for answer. I was trying to read the memory when near the sensor I had transmitter (Miao Miao 2) which during memory dump also accessed it. I assume when MiaoMiao did memory read (unlock -> lock) then it cut my memory read. That would make sense :) So I have the dump exported, but I'm having issues to import it back. I have the full dump export before the sensor went into 06 state and somehow deep inside me believe that importing the whole memory export might bring back the sensor to state when it was useable. I'm experimenting :) i've tried your methods of overwrite early bytes, execute commands E0, E1, E2 but also as you underlined it doesn't bring back the sensor. So going back to my question, when I am trying to import the whole dump I'm having error -
I see it fail at function adr2block -
The beginning of dump has -
1a00 => 0x1A00 So it doesn't fit for the first if I've tried to bypass it and start from next possible address which in the dump is: But then it gives different error -
Do you maybe have any ideas? or maybe you already tried to import full dump back to sensor and it didn't worked also? |
Thanks @gui-dos for response. I think I'll start from this point. @gui-dos you were able to import dumped memory back to sensor? |
@gui-dos Thank you very much for this explanation. Indeed I also seen those videos from Russia where they assembly back sensor to injector to re-apply it, personally I would never attempt that, I am afraid to use fresh kit to apply it to my body and what about custom assembly back... :) I've managed to re-write whole FRAM memory (around 1900 bytes) back to sensor. Re-writed data at first after import shows that CRC of each sections (header, data, footer, patch code) is correct, however after a moment sensor by itself change the CRC of Patch code block and make it incorrect. read=7567 computed=7567 I think this is the thing that for now make the sensor broke (status 0x06) if I understood correctly apart from sensor stage, worktime, history index/results it also check for the CRC's, so it's only one thing that do not match. I've noticed also that you are talking about Libre 2, I am working currently on Libre 1 but definitely your response will help me further with Libre 2, I'll most likely move to it once I'm done with Libre 1. Also Libre 2 is not that much available for now in my country, so I need to wait :) Anyway, thank you a lot for response. |
Ok small update, seems I've corruped the sensor memory somewhere in the middle. After importing memory from different sensor it seems to be fully okay :) |
Hi bro,
I am trying to perform memory dump of RF430TAL152H but unfortunately it keep failing at some point.
Looking at the android studio seems it hang on different sections each time.
Phone is near to the sensor, but it keep failing.
2021-03-20 13:34:27.471 25056-25056/com.kk4vcz.goodv D/GoodV: read(): address=@4678 len=8
2021-03-20 13:34:27.485 25056-25056/com.kk4vcz.goodv D/GoodV: read(): address=@4680 len=8
2021-03-20 13:34:27.499 25056-25056/com.kk4vcz.goodv D/GoodV: read(): address=@4688 len=8
Do you have any ideas? or maybe we can divide the memory into few parts?
The text was updated successfully, but these errors were encountered: