Rebirth of sensor

[hapvlz]

Hello bro,

first of all, thank you for your project. I didn't had chance to use it as I don't have PN5180, but I am doing similar things via android NFC.

I've managed to extend the sensor to 31/41 days (any days). But what problem I've experienced so far is on 28 day the sensor become state 0x06 and it's impossible to rescue it back anymore. I just wonder what is causing it going into 0x06 state. Even after memory reset, right after activation using A0 function its going into 0x06. (Memory reset only in FRAM part). Is there any other sections that also need to be reset?

You mentioned something about battery in your project, not sure if its related, sensor fully responding so far, but maybe there is some inside function that check the battery life, and if its below x% then it will make the sensor 0x06.

Do you have some more ideas? 28 days is pretty nice results, but the sensor was very good till the last minute comparing to glucometer. Skin also looks fine, I don't see a reason to not keep it for longer.

Is there any way to contact you except here?

Thanks, Michal :-)

[captainbeeheart]

Hi Michal, Using Android with Travis work was my next 'TODO' but unfortunately no time yet... Good you can use this.

28 days of total life seems inline with my experiments. I used to rebirth a dead sensor (not same way as Travis) for about 10 more days with valid temperature measurement. In my experiments, the sensor was already in the last state '5' and I didn't test the glycemia, but in average it lasts again for 10 more days providing temperature measurement every minute. This means that the battery inside the sensor can last for about 10 to 14 more days. But careful, the spike measuring the glycemia may be altered by your body, and glycemia measures may not be so accurate...

Once the battery is dead, the sensor cannot work with automatic and periodic measures, but you can re-use it for other power-less tag usage with your own application code in the FRAM. It works very well when powered by NFC only (Did a lot of work with removing the battery and only powering the sensor with NFC).

In case you have state '6' and the sensor is still responding to the NFC, this is not a brick ! (You can brick them if the software section CRC is not good, then the RF API function is not loaded, so no more NFC interface...) Here are some tips on error codes I reversed ( you can find the byte in https://github.com/captainbeeheart/openfreestyle/blob/master/docs/reverse.md - EndOfLifeData_T -> SensorStateOrError )

ERROR_CODES={ 0x7 : "PATCH_TABLE_CHECKSUM_ERROR", 0x8 : "PATCH_TABLE_TABLE_TOO_LONG_ERROR", 0x9 : "PATCH_TABLE_TOO_MANY_ENTRIES_ERROR",
0x0A: "VDDH_RESET_ERROR", 0x0B: "START_RFPMMCTL1_ERROR", 0x0C: "START_CRC_SECTION1_ERROR", 0x0E: "FOOTER_CRC_ERROR", 0x0F: "PATCH_CODE_CRC_ERROR", 0x10: "FRAM_WRITE_PROTECT_ERROR", 0x28: "POWER_ON_BATTERY_ERROR", 0x34: "UNK_ERROR"
}

SENSOR_STATUS={ 1: "NOT_STARTED" , 2: "WARM_UP" , 3: "READY_WORKING" , 4: "EXPIRED" , 5: "SHUT_DOWN" , 6: "FAILURE"
}

you can contact me directly on protonmail. Hope this gives you some answers ! Cap'

[hapvlz]

Hi,

I've dropped you mail however I am not sure if the mail is correct as I couldn't find your address anywhere, but I guessed it can be same as your username here.

Anyway will also reply here. First of all, thank you for your answer it was really useful.

So let me summarize, I've already managed to extend the sensor via two ways:

• Change the maximum life for the sensor from 14 days to 31 (or any higher amount) + update CRC
• Reset the worktime of the sensor + clean glucose history (like E0 command would do) + update CRC

Both ways seems to be working, however max what I could get so far is 28 days (with method of 31 days) I wonder if we can go beyound that 28 days or it's some hardware limit (like you say battery).

What exactly happened? Sensor was fully working and giving perfect results on 28 day, but in middle of the day the sensor by itself went into 0x06 state (Broken) for no reason, I didn't play with it.

I just can't understand why it decided to go into this state or what caused it.

In case you have state '6' and the sensor is still responding to the NFC, this is not a brick ! (You can brick them if the software section CRC is not good, then the RF API function is not loaded, so no more NFC interface...)

I've written simple android application that check the CRC of the whole FRAM, it was fully ok for each section (header, body, footer, commands).

I've tried to import again whole FRAM memory of the same sensor but from 27 days back (from moment when it was right after activation) - unfortunately sensor also become immediately in broken status.

I've tried to reset the sensor (like E0 command would do), it went into 0x02 state (To activate) and after activation with A0 command it become imediately broken.

Not sure what caused this behavior.

Once the battery is dead, the sensor cannot work with automatic and periodic measures, but you can re-use it for other power-less tag usage with your own application code in the FRAM. It works very well when powered by NFC only (Did a lot of work with removing the battery and only powering the sensor with NFC).

With this statement you surprised me, "re-use it with other power-less tag usage with your own application code in the FRAM" I do not fully get this idea. hmm :) Sounds very interesting.

btw. Thank you for the error codes in header section! I wasn't aware of them, checked some of my tests sensors. Do you maybe have some more explanation for some of the error codes? for ex. one of the sensor have: 0x0A: "VDDH_RESET_ERROR", as per google VDDH is something related to the voltage, so I assume the battery is not enough good anymore to keep the sensor alive.

Another one have 0x8 : "PATCH_TABLE_TABLE_TOO_LONG_ERROR", but also not much idea what could it mean.

[keencave]

My analysis result to 0x0A: 0x0A, VDD2X voltage error, active low reset signal of VDD2X voltage occured, RFP MM IRQ according to RFPMM.... set in processElapsedMinutes()/IRQ_RFPMM(). Shut down sensor with status 6. Remark: Only one time tested if minutesElapsed == 1 - happens direct at sensor start Tested one time before entering main thread funcion Remark: VDD2X is 3 V, generated by an internal step up converter. Used to drvie external pripherie. 0x0B, error in activation of the voltage system or voltage VDDBSW error (battery low indicated by corresponding reset bit in RFPMMCTL1), checked in initSystemVoltagesm, called from rf_custom_A0_ROM() aka custom A0 command via NFC, shut down sensor with status 6 or 0xa/0xb from lastResetCause() - also VDDBSW voltage error Remark: VDDSW is the battery voltage (1,5 V)

[hapvlz]

Hello @keencave,

thank you for response and analysis, amazing work. Did you manage to bypass it somehow?

What surprise me is that the sensor when arrive (brand new packed) is already running and responsible for NFC requests. Which means that the battery is actively used and being exhausted even when not activated. With this approach it means that if we keep the sensor (not activated) in box for a month then on first activation it will raise voltage issues? That would be strange.

My understanding can be wrong, I only assume above.

I've ended my attempts after trying to export/import whole memory of the sensor (FRAM/SRAM etc...), unfortunately I couldn't manage to import any other part than FRAM (probably due to limitation, impossibility or lack of my knowledge)

But at the end importing of the whole memory from first day of the sensor might not be helpful due function that check the voltage.

[samivalentim]

@hapvlz could you explain how you did to extend libre?