OVMS v2 Memory/Settings Corruption
Hi all, Thanks to Michaels last message to remind me to ask a question here: Since a few months, maybe a bit more because it happens only once in a while, I have noticed I wasn't receiving the SMS alerts (feature on SMSIP mode) , and sending a "Stats?" only gave me the nasty access denied answer. It turns out, using the application, I noticed that the phone number was getting corrupted (afaik, it's the only setting affected) Normally: "+33651886877" it became "+336k1886877" or "+33651886Z77" etc... like a solar flare bit flip ! It seems it happens only upon reconnection of the ovms module the the OBD plug (Twizy) as, well, the 12V battery, though brand new, can't last a weekend (car parked underground, I suppose the GSM needs to force a bit too much) So question: Has any one suffered from such an issue ? And, otherwise, Michael might be able to tell: Would having the feature on SMS only (without IP) consume less energy ? If so, would it possible to imagine a Hybrid mode, IP active only if vehicle on charge or keyon ? Thanks, JaXX, PS: Despite winter, thinking of building a solar panel + thin plexi sandwich for the rooftop, just because of the 12V battery :-) Only recent twizys can charge the 12V from the traction battery when resting.
Hi Julien, I was lucky to get my charger exchanged just before end of warranty, it's definitely better with the charger keeping the 12V battery up. Tough situation when parking underground. The module may use a lot of energy if the GSM and GPS situation is bad. Switching off GPRS and GPS should save a lot of power then. I'll have a look at it. Have you tried switching off GPRS to see how much that will help? The EEPROM data loss is a known issue, and I'm afraid there's nothing we can do about that. It seems to be a bug in the PIC18. Regards Michael Am 24.11.2016 um 22:10 schrieb Julien Banchet:
Hi all,
Thanks to Michaels last message to remind me to ask a question here:
Since a few months, maybe a bit more because it happens only once in a while, I have noticed I wasn't receiving the SMS alerts (feature on SMSIP mode) , and sending a "Stats?" only gave me the nasty access denied answer.
It turns out, using the application, I noticed that the phone number was getting corrupted (afaik, it's the only setting affected)
Normally: "+33651886877" it became "+336k1886877" or "+33651886Z77" etc... like a solar flare bit flip !
It seems it happens only upon reconnection of the ovms module the the OBD plug (Twizy) as, well, the 12V battery, though brand new, can't last a weekend (car parked underground, I suppose the GSM needs to force a bit too much)
So question: Has any one suffered from such an issue ?
And, otherwise, Michael might be able to tell: Would having the feature on SMS only (without IP) consume less energy ? If so, would it possible to imagine a Hybrid mode, IP active only if vehicle on charge or keyon ?
Thanks,
JaXX, PS: Despite winter, thinking of building a solar panel + thin plexi sandwich for the rooftop, just because of the 12V battery :-) Only recent twizys can charge the 12V from the traction battery when resting.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Hi Michael, And thanks, Mine is a 2012, also got the charger replaced in time, but maybe a simply power-tweaked one at the time... I didn't know it was the charger responsible for deciding to keep the 12v charged (I know it does the charge, though I believed the decision making was done elsewhere) I'll put it in SMS mode tomorrow and see how it goes over the weekend (though I can't monitor the 12V without IP, i'll get the low bettery alerts though ;-) ) Can't wait for V3 ! JaXX./. On Thu, Nov 24, 2016 at 10:47 PM, Michael Balzer <dexter@expeedo.de> wrote:
Hi Julien,
I was lucky to get my charger exchanged just before end of warranty, it's definitely better with the charger keeping the 12V battery up.
Tough situation when parking underground. The module may use a lot of energy if the GSM and GPS situation is bad. Switching off GPRS and GPS should save a lot of power then. I'll have a look at it.
Have you tried switching off GPRS to see how much that will help?
The EEPROM data loss is a known issue, and I'm afraid there's nothing we can do about that. It seems to be a bug in the PIC18.
Regards Michael
Am 24.11.2016 um 22:10 schrieb Julien Banchet:
Hi all,
Thanks to Michaels last message to remind me to ask a question here:
Since a few months, maybe a bit more because it happens only once in a while, I have noticed I wasn't receiving the SMS alerts (feature on SMSIP mode) , and sending a "Stats?" only gave me the nasty access denied answer.
It turns out, using the application, I noticed that the phone number was getting corrupted (afaik, it's the only setting affected)
Normally: "+33651886877" it became "+336k1886877" or "+33651886Z77" etc... like a solar flare bit flip !
It seems it happens only upon reconnection of the ovms module the the OBD plug (Twizy) as, well, the 12V battery, though brand new, can't last a weekend (car parked underground, I suppose the GSM needs to force a bit too much)
So question: Has any one suffered from such an issue ?
And, otherwise, Michael might be able to tell: Would having the feature on SMS only (without IP) consume less energy ? If so, would it possible to imagine a Hybrid mode, IP active only if vehicle on charge or keyon ?
Thanks,
JaXX, PS: Despite winter, thinking of building a solar panel + thin plexi sandwich for the rooftop, just because of the 12V battery :-) Only recent twizys can charge the 12V from the traction battery when resting.
_______________________________________________ OvmsDev mailing listOvmsDev@lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
The two biggest power hogs in OVMS v2 are: The use of a LM to go from 12V -> 5V (blowing off 140%+ as much energy away as heat as we use). Powering on the SIMCOM modem, and maintaining the GPRS connection. The PIC itself uses negligible power, by comparison. Changing that is hard in v2. We can put the modem to sleep, but have no way of remotely waking it up. In OVMS v3, we’ll switch to use a switching power supply. More complex, more noisy, and a little bit more expensive; but much more efficient at bringing 12V down to the levels we need without blowing off heat. The SIMCOM modems have a low power mode where they can maintain a GSM connection, but not GPRS/3G, to drastically reduce power requirements. In that mode they can be woken up by a SMS. If we use Hologram.IO SIMs, where the incoming SMS is free, we could enable a mode where the modem is put to sleep. If an App connects, the server sends a free SMS to the module to wake it up; the module then powers up and establishes GPRS. Without Hologram.IO, we could still do this - but would need some way of remotely waking up the connection. The Wifi/Bluetooth radios have similar capabilities. The framework I’m working on for OVMS v3 includes these low power modes as a fundamental function. I’m confident that we can really bring the power requirements down and offer several different types of low-power sleep mode. Regards, Mark.
On 25 Nov 2016, at 5:59 AM, Julien Banchet <jaxx@jaxx.org> wrote:
Hi Michael,
And thanks,
Mine is a 2012, also got the charger replaced in time, but maybe a simply power-tweaked one at the time... I didn't know it was the charger responsible for deciding to keep the 12v charged (I know it does the charge, though I believed the decision making was done elsewhere)
I'll put it in SMS mode tomorrow and see how it goes over the weekend (though I can't monitor the 12V without IP, i'll get the low bettery alerts though ;-) )
Can't wait for V3 !
JaXX./.
On Thu, Nov 24, 2016 at 10:47 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: Hi Julien,
I was lucky to get my charger exchanged just before end of warranty, it's definitely better with the charger keeping the 12V battery up.
Tough situation when parking underground. The module may use a lot of energy if the GSM and GPS situation is bad. Switching off GPRS and GPS should save a lot of power then. I'll have a look at it.
Have you tried switching off GPRS to see how much that will help?
The EEPROM data loss is a known issue, and I'm afraid there's nothing we can do about that. It seems to be a bug in the PIC18.
Regards Michael
Am 24.11.2016 um 22:10 schrieb Julien Banchet:
Hi all,
Thanks to Michaels last message to remind me to ask a question here:
Since a few months, maybe a bit more because it happens only once in a while, I have noticed I wasn't receiving the SMS alerts (feature on SMSIP mode) , and sending a "Stats?" only gave me the nasty access denied answer.
It turns out, using the application, I noticed that the phone number was getting corrupted (afaik, it's the only setting affected)
Normally: "+33651886877 <tel:%2B33651886877>" it became "+336k1886877" or "+33651886Z77" etc... like a solar flare bit flip !
It seems it happens only upon reconnection of the ovms module the the OBD plug (Twizy) as, well, the 12V battery, though brand new, can't last a weekend (car parked underground, I suppose the GSM needs to force a bit too much)
So question: Has any one suffered from such an issue ?
And, otherwise, Michael might be able to tell: Would having the feature on SMS only (without IP) consume less energy ? If so, would it possible to imagine a Hybrid mode, IP active only if vehicle on charge or keyon ?
Thanks,
JaXX, PS: Despite winter, thinking of building a solar panel + thin plexi sandwich for the rooftop, just because of the 12V battery :-) Only recent twizys can charge the 12V from the traction battery when resting.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
$ perl -e 'printf "%08b\n",ord("5");' 00110101 $ perl -e 'printf "%08b\n",ord("k");' 01101011 $ perl -e 'printf "%08b\n",ord("8");' 00111000 $ perl -e 'printf "%08b\n",ord("Z");' 01011010 Strange. Seems more than a simple bit flip. I haven’t seen this myself, or heard of it much from other users. Is the Twizy code using EEPROM for anything other than settings storage? I know that there are a very limit number of write cycles into that EEPROM space. I did some googling, but all I can find is corruption during writing (either power down, or interrupt during write). But, for our case of very very rare EEPROM writes, that shouldn’t be an issue. Regards, Mark.
On 25 Nov 2016, at 5:47 AM, Michael Balzer <dexter@expeedo.de> wrote:
The EEPROM data loss is a known issue, and I'm afraid there's nothing we can do about that. It seems to be a bug in the PIC18.
Regards Michael
Am 24.11.2016 um 22:10 schrieb Julien Banchet:
Hi all,
Thanks to Michaels last message to remind me to ask a question here:
Since a few months, maybe a bit more because it happens only once in a while, I have noticed I wasn't receiving the SMS alerts (feature on SMSIP mode) , and sending a "Stats?" only gave me the nasty access denied answer.
It turns out, using the application, I noticed that the phone number was getting corrupted (afaik, it's the only setting affected)
Normally: "+33651886877" it became "+336k1886877" or "+33651886Z77" etc... like a solar flare bit flip !_______________________________________________
Sorry, I only gave flaky examples because I switched phones recently and was lazy to digup the old one that had some screenshots Here are some real cases C33651886877 +336518867s7 +3365188T877 +336518868h7 That said, it still is way more than a simple bit flip, and only corrupts the phone number as far as I can recall. I have no explanation, all I can say is, most of the time, I plug the OVMS when I plan charging later in the morning, usually when I'm still underground and a handful of seconds before putting contact (if this can point to any clue) Anyways, gonna try cutting GPRS this morning and see how quick it discharges and might automate switching SMS<->SMSIP once in a while to keep an eye on the battery (my cell operator has an API) though it might wearout eeprom even more :-/ JaXX./. On Fri, Nov 25, 2016 at 1:56 AM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
$ perl -e 'printf "%08b\n",ord("5");' 00110101 $ perl -e 'printf "%08b\n",ord("k");' 01101011 $ perl -e 'printf "%08b\n",ord("8");' 00111000 $ perl -e 'printf "%08b\n",ord("Z");' 01011010
Strange. Seems more than a simple bit flip. I haven’t seen this myself, or heard of it much from other users.
Oh ! This one is impressive Definitly not bit flip nor single caracter screw-up: My phone number became "Topping o"! (I was far from topping off, and the OVMS was plugged 15 minutes before charging the Twizy) Screenshot this morning https://goo.gl/photos/6Yv9TUTTHmQTLosT8 JaXX./. On Fri, Nov 25, 2016 at 8:16 AM, Julien Banchet <jaxx@jaxx.org> wrote:
Sorry, I only gave flaky examples because I switched phones recently and was lazy to digup the old one that had some screenshots
Here are some real cases C33651886877 +336518867s7 +3365188T877 +336518868h7
That said, it still is way more than a simple bit flip, and only corrupts the phone number as far as I can recall.
I have no explanation, all I can say is, most of the time, I plug the OVMS when I plan charging later in the morning, usually when I'm still underground and a handful of seconds before putting contact (if this can point to any clue)
Anyways, gonna try cutting GPRS this morning and see how quick it discharges and might automate switching SMS<->SMSIP once in a while to keep an eye on the battery (my cell operator has an API) though it might wearout eeprom even more :-/
JaXX./.
On Fri, Nov 25, 2016 at 1:56 AM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
$ perl -e 'printf "%08b\n",ord("5");' 00110101 $ perl -e 'printf "%08b\n",ord("k");' 01101011 $ perl -e 'printf "%08b\n",ord("8");' 00111000 $ perl -e 'printf "%08b\n",ord("Z");' 01011010
Strange. Seems more than a simple bit flip. I haven’t seen this myself, or heard of it much from other users.
That really sounds like something writing to EEPROM (but confused and writing the wrong thing). I see in vehicle_twizy.c there are a lot of par_write and par_set. Also some in vehicle_kiasoul.c. Could it be a large number of writes either going through the write cycles of EEPROM, or perhaps showing up a bug in params.c par_write() function? Regards, Mark
On 25 Nov 2016, at 4:38 PM, Julien Banchet <jaxx@jaxx.org> wrote:
Oh ! This one is impressive Definitly not bit flip nor single caracter screw-up: My phone number became "Topping o"! (I was far from topping off, and the OVMS was plugged 15 minutes before charging the Twizy)
Screenshot this morning https://goo.gl/photos/6Yv9TUTTHmQTLosT8 <https://goo.gl/photos/6Yv9TUTTHmQTLosT8>
JaXX./.
On Fri, Nov 25, 2016 at 8:16 AM, Julien Banchet <jaxx@jaxx.org <mailto:jaxx@jaxx.org>> wrote: Sorry, I only gave flaky examples because I switched phones recently and was lazy to digup the old one that had some screenshots
Here are some real cases C33651886877 +336518867s7 +3365188T877 +336518868h7
That said, it still is way more than a simple bit flip, and only corrupts the phone number as far as I can recall.
I have no explanation, all I can say is, most of the time, I plug the OVMS when I plan charging later in the morning, usually when I'm still underground and a handful of seconds before putting contact (if this can point to any clue)
Anyways, gonna try cutting GPRS this morning and see how quick it discharges and might automate switching SMS<->SMSIP once in a while to keep an eye on the battery (my cell operator has an API) though it might wearout eeprom even more :-/
JaXX./.
On Fri, Nov 25, 2016 at 1:56 AM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote: $ perl -e 'printf "%08b\n",ord("5");' 00110101 $ perl -e 'printf "%08b\n",ord("k");' 01101011 $ perl -e 'printf "%08b\n",ord("8");' 00111000 $ perl -e 'printf "%08b\n",ord("Z");' 01011010
Strange. Seems more than a simple bit flip. I haven’t seen this myself, or heard of it much from other users.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
That's much more likely, yes. Besides standard configuration data, the Twizy code uses the EEPROM for the battery capacity average and to store the active tuning profile. So there are more updates to the EEPROM than with other vehicles, but there are no writes to the phone number slot, and there's no large number of writes. PIC18 spec D120: Byte endurance = min. 100K, typ. 1M. So if the profile number feature byte for example is rather bad, and I change my profile 10 times a day (normal: 0), it will wear out after 27 years. IMO there's no way this could be wear related. A bug in par_write() would need to confuse both par_value[] contents and destination address... unlikely. Looks more like some buffer overrun that accidentally also triggers a call to par_write(). Am 25.11.2016 um 10:07 schrieb Mark Webb-Johnson:
That really sounds like something writing to EEPROM (but confused and writing the wrong thing).
I see in vehicle_twizy.c there are a lot of par_write and par_set. Also some in vehicle_kiasoul.c.
Could it be a large number of writes either going through the write cycles of EEPROM, or perhaps showing up a bug in params.c par_write() function?
Regards, Mark
On 25 Nov 2016, at 4:38 PM, Julien Banchet <jaxx@jaxx.org <mailto:jaxx@jaxx.org>> wrote:
Oh ! This one is impressive Definitly not bit flip nor single caracter screw-up: My phone number became "Topping o"! (I was far from topping off, and the OVMS was plugged 15 minutes before charging the Twizy)
Screenshot this morning https://goo.gl/photos/6Yv9TUTTHmQTLosT8
JaXX./.
On Fri, Nov 25, 2016 at 8:16 AM, Julien Banchet <jaxx@jaxx.org <mailto:jaxx@jaxx.org>> wrote:
Sorry, I only gave flaky examples because I switched phones recently and was lazy to digup the old one that had some screenshots
Here are some real cases C33651886877 +336518867s7 +3365188T877 +336518868h7
That said, it still is way more than a simple bit flip, and only corrupts the phone number as far as I can recall.
I have no explanation, all I can say is, most of the time, I plug the OVMS when I plan charging later in the morning, usually when I'm still underground and a handful of seconds before putting contact (if this can point to any clue)
Anyways, gonna try cutting GPRS this morning and see how quick it discharges and might automate switching SMS<->SMSIP once in a while to keep an eye on the battery (my cell operator has an API) though it might wearout eeprom even more :-/
JaXX./.
On Fri, Nov 25, 2016 at 1:56 AM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
$ perl -e 'printf "%08b\n",ord("5");' 00110101 $ perl -e 'printf "%08b\n",ord("k");' 01101011 $ perl -e 'printf "%08b\n",ord("8");' 00111000 $ perl -e 'printf "%08b\n",ord("Z");' 01011010
Strange. Seems more than a simple bit flip. I haven’t seen this myself, or heard of it much from other users.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Hi Greg, welcome :) Juliens parameter #0 has been overwritten with "Topping o", which is part of the charge status message ("Topping off"). So it's much more likely we've got a buffer corruption bug that's triggered by (maybe) bad connectivity situations. Regards, Michael Am 28.11.2016 um 06:38 schrieb Greg D.:
Hi all,
New here, so this may be totally off the wall.
I notice that the first example, with a "5" going to a "k", it may be more easily explained as a bit */shift/* instead of a set of flips. Is there anywhere in the system where the bytes are clocked serially between devices, where there may be some marginal timing?
Just a thought.
Greg.
Mark Webb-Johnson wrote:
$ perl -e 'printf "%08b\n",ord("5");' 00110101 $ perl -e 'printf "%08b\n",ord("k");' 01101011 $ perl -e 'printf "%08b\n",ord("8");' 00111000 $ perl -e 'printf "%08b\n",ord("Z");' 01011010
Strange. Seems more than a simple bit flip. I haven’t seen this myself, or heard of it much from other users.
Is the Twizy code using EEPROM for anything other than settings storage? I know that there are a very limit number of write cycles into that EEPROM space.
I did some googling, but all I can find is corruption during writing (either power down, or interrupt during write). But, for our case of very very rare EEPROM writes, that shouldn’t be an issue.
Regards, Mark.
On 25 Nov 2016, at 5:47 AM, Michael Balzer <dexter@expeedo.de> wrote:
The EEPROM data loss is a known issue, and I'm afraid there's nothing we can do about that. It seems to be a bug in the PIC18.
Regards Michael
Am 24.11.2016 um 22:10 schrieb Julien Banchet:
Hi all,
Thanks to Michaels last message to remind me to ask a question here:
Since a few months, maybe a bit more because it happens only once in a while, I have noticed I wasn't receiving the SMS alerts (feature on SMSIP mode) , and sending a "Stats?" only gave me the nasty access denied answer.
It turns out, using the application, I noticed that the phone number was getting corrupted (afaik, it's the only setting affected)
Normally: "+33651886877" it became "+336k1886877" or "+33651886Z77" etc... like a solar flare bit flip !_______________________________________________
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Hi, And since I'm paying more attention to it, it really seems linked to bad connectivity/GSM coverage, my last "plug in" was outside and it didn't happen. Also having an issue with the SMS / SMSIP setting, it doesn't seem to be taken in account correctly (from seeing the app showing Live, next to 49875 days of parking ;-) ), does it need a reset to get it set properly? (anyways, switched back to an iPhone without the battery voltage showing on the app) Regards, JaXX, dead, having spent the whole day in a datacenter, 1+1h cold trip in the Twizy in parisian traffic. On Mon, Nov 28, 2016 at 7:31 PM, Michael Balzer <dexter@expeedo.de> wrote:
Hi Greg, welcome :)
Juliens parameter #0 has been overwritten with "Topping o", which is part of the charge status message ("Topping off").
So it's much more likely we've got a buffer corruption bug that's triggered by (maybe) bad connectivity situations.
Regards, Michael
Am 28.11.2016 um 06:38 schrieb Greg D.:
Hi all,
New here, so this may be totally off the wall.
I notice that the first example, with a "5" going to a "k", it may be more easily explained as a bit *shift* instead of a set of flips. Is there anywhere in the system where the bytes are clocked serially between devices, where there may be some marginal timing?
Just a thought.
Greg.
Mark Webb-Johnson wrote:
$ perl -e 'printf "%08b\n",ord("5");' 00110101 $ perl -e 'printf "%08b\n",ord("k");' 01101011 $ perl -e 'printf "%08b\n",ord("8");' 00111000 $ perl -e 'printf "%08b\n",ord("Z");' 01011010
Strange. Seems more than a simple bit flip. I haven’t seen this myself, or heard of it much from other users.
Is the Twizy code using EEPROM for anything other than settings storage? I know that there are a very limit number of write cycles into that EEPROM space.
I did some googling, but all I can find is corruption during writing (either power down, or interrupt during write). But, for our case of very very rare EEPROM writes, that shouldn’t be an issue.
Regards, Mark.
On 25 Nov 2016, at 5:47 AM, Michael Balzer <dexter@expeedo.de> <dexter@expeedo.de> wrote:
The EEPROM data loss is a known issue, and I'm afraid there's nothing we can do about that. It seems to be a bug in the PIC18.
Regards Michael
Am 24.11.2016 um 22:10 schrieb Julien Banchet:
Hi all,
Thanks to Michaels last message to remind me to ask a question here:
Since a few months, maybe a bit more because it happens only once in a while, I have noticed I wasn't receiving the SMS alerts (feature on SMSIP mode) , and sending a "Stats?" only gave me the nasty access denied answer.
It turns out, using the application, I noticed that the phone number was getting corrupted (afaik, it's the only setting affected)
Normally: "+33651886877" it became "+336k1886877" or "+33651886Z77" etc... like a solar flare bit flip !_______________________________________________
_______________________________________________ OvmsDev mailing listOvmsDev@lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing listOvmsDev@lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Hi, I also have two cases with parkingtime of 49710 and 17133 days… Regards Pierre Von: ovmsdev-bounces@lists.teslaclub.hk [mailto:ovmsdev-bounces@lists.teslaclub.hk] Im Auftrag von Julien Banchet Gesendet: Montag, 28. November 2016 20:06 An: OVMS Developers <ovmsdev@lists.teslaclub.hk> Betreff: Re: [Ovmsdev] OVMS v2 Memory/Settings Corruption Hi, And since I'm paying more attention to it, it really seems linked to bad connectivity/GSM coverage, my last "plug in" was outside and it didn't happen. Also having an issue with the SMS / SMSIP setting, it doesn't seem to be taken in account correctly (from seeing the app showing Live, next to 49875 days of parking ;-) ), does it need a reset to get it set properly? (anyways, switched back to an iPhone without the battery voltage showing on the app) Regards, JaXX, dead, having spent the whole day in a datacenter, 1+1h cold trip in the Twizy in parisian traffic. On Mon, Nov 28, 2016 at 7:31 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de> > wrote: Hi Greg, welcome :) Juliens parameter #0 has been overwritten with "Topping o", which is part of the charge status message ("Topping off"). So it's much more likely we've got a buffer corruption bug that's triggered by (maybe) bad connectivity situations. Regards, Michael Am 28.11.2016 um 06:38 schrieb Greg D.: Hi all, New here, so this may be totally off the wall. I notice that the first example, with a "5" going to a "k", it may be more easily explained as a bit shift instead of a set of flips. Is there anywhere in the system where the bytes are clocked serially between devices, where there may be some marginal timing? Just a thought. Greg. Mark Webb-Johnson wrote: $ perl -e 'printf "%08b\n",ord("5");' 00110101 $ perl -e 'printf "%08b\n",ord("k");' 01101011 $ perl -e 'printf "%08b\n",ord("8");' 00111000 $ perl -e 'printf "%08b\n",ord("Z");' 01011010 Strange. Seems more than a simple bit flip. I haven’t seen this myself, or heard of it much from other users. Is the Twizy code using EEPROM for anything other than settings storage? I know that there are a very limit number of write cycles into that EEPROM space. I did some googling, but all I can find is corruption during writing (either power down, or interrupt during write). But, for our case of very very rare EEPROM writes, that shouldn’t be an issue. Regards, Mark. On 25 Nov 2016, at 5:47 AM, Michael Balzer <mailto:dexter@expeedo.de> <dexter@expeedo.de> wrote: The EEPROM data loss is a known issue, and I'm afraid there's nothing we can do about that. It seems to be a bug in the PIC18. Regards Michael Am 24.11.2016 um 22:10 schrieb Julien Banchet: Hi all, Thanks to Michaels last message to remind me to ask a question here: Since a few months, maybe a bit more because it happens only once in a while, I have noticed I wasn't receiving the SMS alerts (feature on SMSIP mode) , and sending a "Stats?" only gave me the nasty access denied answer. It turns out, using the application, I noticed that the phone number was getting corrupted (afaik, it's the only setting affected) Normally: "+33651886877 <tel:%2B33651886877> " it became "+336k1886877" or "+33651886Z77" etc... like a solar flare bit flip !_______________________________________________ _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
There's no memory management in the module, there's too few RAM available to do dynamic allocations. All buffers are static, the error can be some pointer corruption or missing length check / end of string check. A stack overflow could also be possible, the software stack is 256 bytes (1 page). As there's not enough ROM left to support the crash debug framework anymore in the Twizy build, I cannot tell if that happens again. Julien, you could try a reduced build with crash debug recording enabled... Regards, Michael Am 28.11.2016 um 22:00 schrieb Greg D.:
Ah! That sounds much more likely.
Is there an error (timeout) path that might be freeing the buffer when it's still in use?
Greg.
Michael Balzer wrote:
Hi Greg, welcome :)
Juliens parameter #0 has been overwritten with "Topping o", which is part of the charge status message ("Topping off").
So it's much more likely we've got a buffer corruption bug that's triggered by (maybe) bad connectivity situations.
Regards, Michael
Am 28.11.2016 um 06:38 schrieb Greg D.:
Hi all,
New here, so this may be totally off the wall.
I notice that the first example, with a "5" going to a "k", it may be more easily explained as a bit */shift/* instead of a set of flips. Is there anywhere in the system where the bytes are clocked serially between devices, where there may be some marginal timing?
Just a thought.
Greg.
Mark Webb-Johnson wrote:
$ perl -e 'printf "%08b\n",ord("5");' 00110101 $ perl -e 'printf "%08b\n",ord("k");' 01101011 $ perl -e 'printf "%08b\n",ord("8");' 00111000 $ perl -e 'printf "%08b\n",ord("Z");' 01011010
Strange. Seems more than a simple bit flip. I haven’t seen this myself, or heard of it much from other users.
Is the Twizy code using EEPROM for anything other than settings storage? I know that there are a very limit number of write cycles into that EEPROM space.
I did some googling, but all I can find is corruption during writing (either power down, or interrupt during write). But, for our case of very very rare EEPROM writes, that shouldn’t be an issue.
Regards, Mark.
On 25 Nov 2016, at 5:47 AM, Michael Balzer <dexter@expeedo.de> wrote:
The EEPROM data loss is a known issue, and I'm afraid there's nothing we can do about that. It seems to be a bug in the PIC18.
Regards Michael
Am 24.11.2016 um 22:10 schrieb Julien Banchet:
Hi all,
Thanks to Michaels last message to remind me to ask a question here:
Since a few months, maybe a bit more because it happens only once in a while, I have noticed I wasn't receiving the SMS alerts (feature on SMSIP mode) , and sending a "Stats?" only gave me the nasty access denied answer.
It turns out, using the application, I noticed that the phone number was getting corrupted (afaik, it's the only setting affected)
Normally: "+33651886877" it became "+336k1886877" or "+33651886Z77" etc... like a solar flare bit flip !_______________________________________________
OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Sure Michael, I've never got around compiling it right, and I'm out of a Windows since, wow, I don't even know if grub would boot the partition anymore... If you have it under hand (i hope), I'd be happy to give it a shot, it would also be the occasion for me next weekend to pull a ribbon cable out once and for all (or find a clever way to keep it hidden though programmable) How does crash recording work ? over Diag ? (PS: 50M/month data if needed) Julien ./. On Mon, Nov 28, 2016 at 10:16 PM, Michael Balzer <dexter@expeedo.de> wrote:
There's no memory management in the module, there's too few RAM available to do dynamic allocations.
All buffers are static, the error can be some pointer corruption or missing length check / end of string check.
A stack overflow could also be possible, the software stack is 256 bytes (1 page). As there's not enough ROM left to support the crash debug framework anymore in the Twizy build, I cannot tell if that happens again.
Julien, you could try a reduced build with crash debug recording enabled...
Regards, Michael
Am 28.11.2016 um 22:00 schrieb Greg D.:
Ah! That sounds much more likely.
Is there an error (timeout) path that might be freeing the buffer when it's still in use?
Greg.
Michael Balzer wrote:
Hi Greg, welcome :)
Juliens parameter #0 has been overwritten with "Topping o", which is part of the charge status message ("Topping off").
So it's much more likely we've got a buffer corruption bug that's triggered by (maybe) bad connectivity situations.
Regards, Michael
Am 28.11.2016 um 06:38 schrieb Greg D.:
Hi all,
New here, so this may be totally off the wall.
I notice that the first example, with a "5" going to a "k", it may be more easily explained as a bit *shift* instead of a set of flips. Is there anywhere in the system where the bytes are clocked serially between devices, where there may be some marginal timing?
Just a thought.
Greg.
Mark Webb-Johnson wrote:
$ perl -e 'printf "%08b\n",ord("5");' 00110101 $ perl -e 'printf "%08b\n",ord("k");' 01101011 $ perl -e 'printf "%08b\n",ord("8");' 00111000 $ perl -e 'printf "%08b\n",ord("Z");' 01011010
Strange. Seems more than a simple bit flip. I haven’t seen this myself, or heard of it much from other users.
Is the Twizy code using EEPROM for anything other than settings storage? I know that there are a very limit number of write cycles into that EEPROM space.
I did some googling, but all I can find is corruption during writing (either power down, or interrupt during write). But, for our case of very very rare EEPROM writes, that shouldn’t be an issue.
Regards, Mark.
On 25 Nov 2016, at 5:47 AM, Michael Balzer <dexter@expeedo.de> <dexter@expeedo.de> wrote:
The EEPROM data loss is a known issue, and I'm afraid there's nothing we can do about that. It seems to be a bug in the PIC18.
Regards Michael
Am 24.11.2016 um 22:10 schrieb Julien Banchet:
Hi all,
Thanks to Michaels last message to remind me to ask a question here:
Since a few months, maybe a bit more because it happens only once in a while, I have noticed I wasn't receiving the SMS alerts (feature on SMSIP mode) , and sending a "Stats?" only gave me the nasty access denied answer.
It turns out, using the application, I noticed that the phone number was getting corrupted (afaik, it's the only setting affected)
Normally: "+33651886877" it became "+336k1886877" or "+33651886Z77" etc... like a solar flare bit flip !_______________________________________________
_______________________________________________ OvmsDev mailing listOvmsDev@lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing listOvmsDev@lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing listOvmsDev@lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing listOvmsDev@lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Julien, Pierre, here's a firmware build with crash debug enabled: https://dexters-web.de/f/tw-beta/OVMS-Twizy-3.8.2-crashdebug.zip It excludes the diag mode (serial interface command shell) but is otherwise complete. The crash debug logs to the server (when it is/becomes available), historical record type "*-OVM-DebugCrash". These records expire after 30 days, so you can collect some days. The crash count and data from the most recent crash will also be shown by the SMS/text command "DIAG". The crash records contain a crash count, crash reasons (flags from RCON) and the last checkpoint seen before the crash. Regards, Michael Am 28.11.2016 um 22:37 schrieb Julien Banchet:
Sure Michael,
I've never got around compiling it right, and I'm out of a Windows since, wow, I don't even know if grub would boot the partition anymore... If you have it under hand (i hope), I'd be happy to give it a shot, it would also be the occasion for me next weekend to pull a ribbon cable out once and for all (or find a clever way to keep it hidden though programmable)
How does crash recording work ? over Diag ? (PS: 50M/month data if needed)
Julien ./.
On Mon, Nov 28, 2016 at 10:16 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
There's no memory management in the module, there's too few RAM available to do dynamic allocations.
All buffers are static, the error can be some pointer corruption or missing length check / end of string check.
A stack overflow could also be possible, the software stack is 256 bytes (1 page). As there's not enough ROM left to support the crash debug framework anymore in the Twizy build, I cannot tell if that happens again.
Julien, you could try a reduced build with crash debug recording enabled...
Regards, Michael
Am 28.11.2016 um 22:00 schrieb Greg D.:
Ah! That sounds much more likely.
Is there an error (timeout) path that might be freeing the buffer when it's still in use?
Greg.
Michael Balzer wrote:
Hi Greg, welcome :)
Juliens parameter #0 has been overwritten with "Topping o", which is part of the charge status message ("Topping off").
So it's much more likely we've got a buffer corruption bug that's triggered by (maybe) bad connectivity situations.
Regards, Michael
Am 28.11.2016 um 06:38 schrieb Greg D.:
Hi all,
New here, so this may be totally off the wall.
I notice that the first example, with a "5" going to a "k", it may be more easily explained as a bit */shift/* instead of a set of flips. Is there anywhere in the system where the bytes are clocked serially between devices, where there may be some marginal timing?
Just a thought.
Greg.
Mark Webb-Johnson wrote:
$ perl -e 'printf "%08b\n",ord("5");' 00110101 $ perl -e 'printf "%08b\n",ord("k");' 01101011 $ perl -e 'printf "%08b\n",ord("8");' 00111000 $ perl -e 'printf "%08b\n",ord("Z");' 01011010
Strange. Seems more than a simple bit flip. I haven’t seen this myself, or heard of it much from other users.
Is the Twizy code using EEPROM for anything other than settings storage? I know that there are a very limit number of write cycles into that EEPROM space.
I did some googling, but all I can find is corruption during writing (either power down, or interrupt during write). But, for our case of very very rare EEPROM writes, that shouldn’t be an issue.
Regards, Mark.
On 25 Nov 2016, at 5:47 AM, Michael Balzer <dexter@expeedo.de> <mailto:dexter@expeedo.de> wrote:
The EEPROM data loss is a known issue, and I'm afraid there's nothing we can do about that. It seems to be a bug in the PIC18.
Regards Michael
Am 24.11.2016 um 22:10 schrieb Julien Banchet: > Hi all, > > Thanks to Michaels last message to remind me to ask a question here: > > Since a few months, maybe a bit more because it happens only once in a while, I have noticed I wasn't receiving the SMS alerts (feature on SMSIP mode) , and sending a "Stats?" only gave me the nasty access denied answer. > > It turns out, using the application, I noticed that the phone number was getting corrupted (afaik, it's the only setting affected) > > Normally: "+33651886877 <tel:%2B33651886877>" it became "+336k1886877" or "+33651886Z77" etc... like a solar flare bit flip !_______________________________________________
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Thank you Michael, Will flash it this weekend! MfG, JaXX./. On Tue, Nov 29, 2016 at 10:10 PM, Michael Balzer <dexter@expeedo.de> wrote:
Julien, Pierre,
here's a firmware build with crash debug enabled: https://dexters-web.de/f/tw-beta/OVMS-Twizy-3.8.2-crashdebug.zip
It excludes the diag mode (serial interface command shell) but is otherwise complete.
The crash debug logs to the server (when it is/becomes available), historical record type "*-OVM-DebugCrash". These records expire after 30 days, so you can collect some days.
The crash count and data from the most recent crash will also be shown by the SMS/text command "DIAG".
The crash records contain a crash count, crash reasons (flags from RCON) and the last checkpoint seen before the crash.
Regards, Michael
Am 28.11.2016 um 22:37 schrieb Julien Banchet:
Sure Michael,
I've never got around compiling it right, and I'm out of a Windows since, wow, I don't even know if grub would boot the partition anymore... If you have it under hand (i hope), I'd be happy to give it a shot, it would also be the occasion for me next weekend to pull a ribbon cable out once and for all (or find a clever way to keep it hidden though programmable)
How does crash recording work ? over Diag ? (PS: 50M/month data if needed)
Julien ./.
On Mon, Nov 28, 2016 at 10:16 PM, Michael Balzer <dexter@expeedo.de> wrote:
There's no memory management in the module, there's too few RAM available to do dynamic allocations.
All buffers are static, the error can be some pointer corruption or missing length check / end of string check.
A stack overflow could also be possible, the software stack is 256 bytes (1 page). As there's not enough ROM left to support the crash debug framework anymore in the Twizy build, I cannot tell if that happens again.
Julien, you could try a reduced build with crash debug recording enabled...
Regards, Michael
Am 28.11.2016 um 22:00 schrieb Greg D.:
Ah! That sounds much more likely.
Is there an error (timeout) path that might be freeing the buffer when it's still in use?
Greg.
Michael Balzer wrote:
Hi Greg, welcome :)
Juliens parameter #0 has been overwritten with "Topping o", which is part of the charge status message ("Topping off").
So it's much more likely we've got a buffer corruption bug that's triggered by (maybe) bad connectivity situations.
Regards, Michael
Am 28.11.2016 um 06:38 schrieb Greg D.:
Hi all,
New here, so this may be totally off the wall.
I notice that the first example, with a "5" going to a "k", it may be more easily explained as a bit *shift* instead of a set of flips. Is there anywhere in the system where the bytes are clocked serially between devices, where there may be some marginal timing?
Just a thought.
Greg.
Mark Webb-Johnson wrote:
$ perl -e 'printf "%08b\n",ord("5");' 00110101 $ perl -e 'printf "%08b\n",ord("k");' 01101011 $ perl -e 'printf "%08b\n",ord("8");' 00111000 $ perl -e 'printf "%08b\n",ord("Z");' 01011010
Strange. Seems more than a simple bit flip. I haven’t seen this myself, or heard of it much from other users.
Is the Twizy code using EEPROM for anything other than settings storage? I know that there are a very limit number of write cycles into that EEPROM space.
I did some googling, but all I can find is corruption during writing (either power down, or interrupt during write). But, for our case of very very rare EEPROM writes, that shouldn’t be an issue.
Regards, Mark.
On 25 Nov 2016, at 5:47 AM, Michael Balzer <dexter@expeedo.de> <dexter@expeedo.de> wrote:
The EEPROM data loss is a known issue, and I'm afraid there's nothing we can do about that. It seems to be a bug in the PIC18.
Regards Michael
Am 24.11.2016 um 22:10 schrieb Julien Banchet:
Hi all,
Thanks to Michaels last message to remind me to ask a question here:
Since a few months, maybe a bit more because it happens only once in a while, I have noticed I wasn't receiving the SMS alerts (feature on SMSIP mode) , and sending a "Stats?" only gave me the nasty access denied answer.
It turns out, using the application, I noticed that the phone number was getting corrupted (afaik, it's the only setting affected)
Normally: "+33651886877" it became "+336k1886877" or "+33651886Z77" etc... like a solar flare bit flip !_______________________________________________
_______________________________________________ OvmsDev mailing listOvmsDev@lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing listOvmsDev@lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing listOvmsDev@lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing listOvmsDev@lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mail man/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing listOvmsDev@lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Got the buffer overrun effect today with the new release. As I now...
- Keep volatile features over reset
...it now also shows up with random data in features 0-7. Annoying. Julien, Pierre, any crash debug data collected yet? Regards, Michael Am 29.11.2016 um 22:13 schrieb Julien Banchet:
Thank you Michael, Will flash it this weekend!
MfG, JaXX./.
On Tue, Nov 29, 2016 at 10:10 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Julien, Pierre,
here's a firmware build with crash debug enabled: https://dexters-web.de/f/tw-beta/OVMS-Twizy-3.8.2-crashdebug.zip <https://dexters-web.de/f/tw-beta/OVMS-Twizy-3.8.2-crashdebug.zip>
It excludes the diag mode (serial interface command shell) but is otherwise complete.
The crash debug logs to the server (when it is/becomes available), historical record type "*-OVM-DebugCrash". These records expire after 30 days, so you can collect some days.
The crash count and data from the most recent crash will also be shown by the SMS/text command "DIAG".
The crash records contain a crash count, crash reasons (flags from RCON) and the last checkpoint seen before the crash.
Regards, Michael
Am 28.11.2016 um 22:37 schrieb Julien Banchet:
Sure Michael,
I've never got around compiling it right, and I'm out of a Windows since, wow, I don't even know if grub would boot the partition anymore... If you have it under hand (i hope), I'd be happy to give it a shot, it would also be the occasion for me next weekend to pull a ribbon cable out once and for all (or find a clever way to keep it hidden though programmable)
How does crash recording work ? over Diag ? (PS: 50M/month data if needed)
Julien ./.
On Mon, Nov 28, 2016 at 10:16 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
There's no memory management in the module, there's too few RAM available to do dynamic allocations.
All buffers are static, the error can be some pointer corruption or missing length check / end of string check.
A stack overflow could also be possible, the software stack is 256 bytes (1 page). As there's not enough ROM left to support the crash debug framework anymore in the Twizy build, I cannot tell if that happens again.
Julien, you could try a reduced build with crash debug recording enabled...
Regards, Michael
Am 28.11.2016 um 22:00 schrieb Greg D.:
Ah! That sounds much more likely.
Is there an error (timeout) path that might be freeing the buffer when it's still in use?
Greg.
Michael Balzer wrote:
Hi Greg, welcome :)
Juliens parameter #0 has been overwritten with "Topping o", which is part of the charge status message ("Topping off").
So it's much more likely we've got a buffer corruption bug that's triggered by (maybe) bad connectivity situations.
Regards, Michael
Am 28.11.2016 um 06:38 schrieb Greg D.:
Hi all,
New here, so this may be totally off the wall.
I notice that the first example, with a "5" going to a "k", it may be more easily explained as a bit */shift/* instead of a set of flips. Is there anywhere in the system where the bytes are clocked serially between devices, where there may be some marginal timing?
Just a thought.
Greg.
Mark Webb-Johnson wrote:
$ perl -e 'printf "%08b\n",ord("5");' 00110101 $ perl -e 'printf "%08b\n",ord("k");' 01101011 $ perl -e 'printf "%08b\n",ord("8");' 00111000 $ perl -e 'printf "%08b\n",ord("Z");' 01011010
Strange. Seems more than a simple bit flip. I haven’t seen this myself, or heard of it much from other users.
Is the Twizy code using EEPROM for anything other than settings storage? I know that there are a very limit number of write cycles into that EEPROM space.
I did some googling, but all I can find is corruption during writing (either power down, or interrupt during write). But, for our case of very very rare EEPROM writes, that shouldn’t be an issue.
Regards, Mark.
> On 25 Nov 2016, at 5:47 AM, Michael Balzer <dexter@expeedo.de> <mailto:dexter@expeedo.de> wrote: > > The EEPROM data loss is a known issue, and I'm afraid there's nothing we can do about that. It seems to be a bug in the PIC18. > > Regards > Michael > > Am 24.11.2016 um 22:10 schrieb Julien Banchet: >> Hi all, >> >> Thanks to Michaels last message to remind me to ask a question here: >> >> Since a few months, maybe a bit more because it happens only once in a while, I have noticed I wasn't receiving the SMS alerts (feature on SMSIP mode) , and sending a "Stats?" only gave me the nasty access denied answer. >> >> It turns out, using the application, I noticed that the phone number was getting corrupted (afaik, it's the only setting affected) >> >> Normally: "+33651886877 <tel:%2B33651886877>" it became "+336k1886877" or "+33651886Z77" etc... like a solar flare bit flip !_______________________________________________ _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Got the buffer overrun effect yesterday with the new release. As I now...
- Keep volatile features over reset
...it now also shows up with random data in features 0-7. Annoying. Julien, Pierre, any crash debug data collected yet? Regards, Michael Am 29.11.2016 um 22:13 schrieb Julien Banchet:
Thank you Michael, Will flash it this weekend!
MfG, JaXX./.
On Tue, Nov 29, 2016 at 10:10 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Julien, Pierre,
here's a firmware build with crash debug enabled: https://dexters-web.de/f/tw-beta/OVMS-Twizy-3.8.2-crashdebug.zip <https://dexters-web.de/f/tw-beta/OVMS-Twizy-3.8.2-crashdebug.zip>
It excludes the diag mode (serial interface command shell) but is otherwise complete.
The crash debug logs to the server (when it is/becomes available), historical record type "*-OVM-DebugCrash". These records expire after 30 days, so you can collect some days.
The crash count and data from the most recent crash will also be shown by the SMS/text command "DIAG".
The crash records contain a crash count, crash reasons (flags from RCON) and the last checkpoint seen before the crash.
Regards, Michael
Am 28.11.2016 um 22:37 schrieb Julien Banchet:
Sure Michael,
I've never got around compiling it right, and I'm out of a Windows since, wow, I don't even know if grub would boot the partition anymore... If you have it under hand (i hope), I'd be happy to give it a shot, it would also be the occasion for me next weekend to pull a ribbon cable out once and for all (or find a clever way to keep it hidden though programmable)
How does crash recording work ? over Diag ? (PS: 50M/month data if needed)
Julien ./.
On Mon, Nov 28, 2016 at 10:16 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
There's no memory management in the module, there's too few RAM available to do dynamic allocations.
All buffers are static, the error can be some pointer corruption or missing length check / end of string check.
A stack overflow could also be possible, the software stack is 256 bytes (1 page). As there's not enough ROM left to support the crash debug framework anymore in the Twizy build, I cannot tell if that happens again.
Julien, you could try a reduced build with crash debug recording enabled...
Regards, Michael
Am 28.11.2016 um 22:00 schrieb Greg D.:
Ah! That sounds much more likely.
Is there an error (timeout) path that might be freeing the buffer when it's still in use?
Greg.
Michael Balzer wrote:
Hi Greg, welcome :)
Juliens parameter #0 has been overwritten with "Topping o", which is part of the charge status message ("Topping off").
So it's much more likely we've got a buffer corruption bug that's triggered by (maybe) bad connectivity situations.
Regards, Michael
Am 28.11.2016 um 06:38 schrieb Greg D.:
Hi all,
New here, so this may be totally off the wall.
I notice that the first example, with a "5" going to a "k", it may be more easily explained as a bit */shift/* instead of a set of flips. Is there anywhere in the system where the bytes are clocked serially between devices, where there may be some marginal timing?
Just a thought.
Greg.
Mark Webb-Johnson wrote:
$ perl -e 'printf "%08b\n",ord("5");' 00110101 $ perl -e 'printf "%08b\n",ord("k");' 01101011 $ perl -e 'printf "%08b\n",ord("8");' 00111000 $ perl -e 'printf "%08b\n",ord("Z");' 01011010
Strange. Seems more than a simple bit flip. I haven’t seen this myself, or heard of it much from other users.
Is the Twizy code using EEPROM for anything other than settings storage? I know that there are a very limit number of write cycles into that EEPROM space.
I did some googling, but all I can find is corruption during writing (either power down, or interrupt during write). But, for our case of very very rare EEPROM writes, that shouldn’t be an issue.
Regards, Mark.
> On 25 Nov 2016, at 5:47 AM, Michael Balzer <dexter@expeedo.de> <mailto:dexter@expeedo.de> wrote: > > The EEPROM data loss is a known issue, and I'm afraid there's nothing we can do about that. It seems to be a bug in the PIC18. > > Regards > Michael > > Am 24.11.2016 um 22:10 schrieb Julien Banchet: >> Hi all, >> >> Thanks to Michaels last message to remind me to ask a question here: >> >> Since a few months, maybe a bit more because it happens only once in a while, I have noticed I wasn't receiving the SMS alerts (feature on SMSIP mode) , and sending a "Stats?" only gave me the nasty access denied answer. >> >> It turns out, using the application, I noticed that the phone number was getting corrupted (afaik, it's the only setting affected) >> >> Normally: "+33651886877 <tel:%2B33651886877>" it became "+336k1886877" or "+33651886Z77" etc... like a solar flare bit flip !_______________________________________________ _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Sorry Michael, Haven't really had the time yet (medical emergency last weekend, on call with work this weekend... the Telco industry never sleeps :-) ) (The hiccup happened again on thursday, phone number became "+3365" instead of "+33651886877") I'll be jobless after december 13th (no problem, got a year and a half of paid vacation to get paid ;-) ) so I'll have a little bit of time to flash the code in before visiting family. JaXX./. On Sun, Dec 11, 2016 at 8:57 AM, Michael Balzer <dexter@expeedo.de> wrote:
Got the buffer overrun effect yesterday with the new release.
As I now...
- Keep volatile features over reset
...it now also shows up with random data in features 0-7. Annoying.
Julien, Pierre, any crash debug data collected yet?
Regards, Michael
Am 29.11.2016 um 22:13 schrieb Julien Banchet:
Thank you Michael, Will flash it this weekend!
MfG, JaXX./.
On Tue, Nov 29, 2016 at 10:10 PM, Michael Balzer <dexter@expeedo.de> wrote:
Julien, Pierre,
here's a firmware build with crash debug enabled: https://dexters-web.de/f/tw-beta/OVMS-Twizy-3.8.2-crashdebug.zip
It excludes the diag mode (serial interface command shell) but is otherwise complete.
The crash debug logs to the server (when it is/becomes available), historical record type "*-OVM-DebugCrash". These records expire after 30 days, so you can collect some days.
The crash count and data from the most recent crash will also be shown by the SMS/text command "DIAG".
The crash records contain a crash count, crash reasons (flags from RCON) and the last checkpoint seen before the crash.
Regards, Michael
Am 28.11.2016 um 22:37 schrieb Julien Banchet:
Sure Michael,
I've never got around compiling it right, and I'm out of a Windows since, wow, I don't even know if grub would boot the partition anymore... If you have it under hand (i hope), I'd be happy to give it a shot, it would also be the occasion for me next weekend to pull a ribbon cable out once and for all (or find a clever way to keep it hidden though programmable)
How does crash recording work ? over Diag ? (PS: 50M/month data if needed)
Julien ./.
On Mon, Nov 28, 2016 at 10:16 PM, Michael Balzer <dexter@expeedo.de> wrote:
There's no memory management in the module, there's too few RAM available to do dynamic allocations.
All buffers are static, the error can be some pointer corruption or missing length check / end of string check.
A stack overflow could also be possible, the software stack is 256 bytes (1 page). As there's not enough ROM left to support the crash debug framework anymore in the Twizy build, I cannot tell if that happens again.
Julien, you could try a reduced build with crash debug recording enabled...
Regards, Michael
Am 28.11.2016 um 22:00 schrieb Greg D.:
Ah! That sounds much more likely.
Is there an error (timeout) path that might be freeing the buffer when it's still in use?
Greg.
Michael Balzer wrote:
Hi Greg, welcome :)
Juliens parameter #0 has been overwritten with "Topping o", which is part of the charge status message ("Topping off").
So it's much more likely we've got a buffer corruption bug that's triggered by (maybe) bad connectivity situations.
Regards, Michael
Am 28.11.2016 um 06:38 schrieb Greg D.:
Hi all,
New here, so this may be totally off the wall.
I notice that the first example, with a "5" going to a "k", it may be more easily explained as a bit *shift* instead of a set of flips. Is there anywhere in the system where the bytes are clocked serially between devices, where there may be some marginal timing?
Just a thought.
Greg.
Mark Webb-Johnson wrote:
$ perl -e 'printf "%08b\n",ord("5");' 00110101 $ perl -e 'printf "%08b\n",ord("k");' 01101011 $ perl -e 'printf "%08b\n",ord("8");' 00111000 $ perl -e 'printf "%08b\n",ord("Z");' 01011010
Strange. Seems more than a simple bit flip. I haven’t seen this myself, or heard of it much from other users.
Is the Twizy code using EEPROM for anything other than settings storage? I know that there are a very limit number of write cycles into that EEPROM space.
I did some googling, but all I can find is corruption during writing (either power down, or interrupt during write). But, for our case of very very rare EEPROM writes, that shouldn’t be an issue.
Regards, Mark.
On 25 Nov 2016, at 5:47 AM, Michael Balzer <dexter@expeedo.de> <dexter@expeedo.de> wrote:
The EEPROM data loss is a known issue, and I'm afraid there's nothing we can do about that. It seems to be a bug in the PIC18.
Regards Michael
Am 24.11.2016 um 22:10 schrieb Julien Banchet:
Hi all,
Thanks to Michaels last message to remind me to ask a question here:
Since a few months, maybe a bit more because it happens only once in a while, I have noticed I wasn't receiving the SMS alerts (feature on SMSIP mode) , and sending a "Stats?" only gave me the nasty access denied answer.
It turns out, using the application, I noticed that the phone number was getting corrupted (afaik, it's the only setting affected)
Normally: "+33651886877" it became "+336k1886877" or "+33651886Z77" etc... like a solar flare bit flip !_______________________________________________
_______________________________________________ OvmsDev mailing listOvmsDev@lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing listOvmsDev@lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing listOvmsDev@lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing listOvmsDev@lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mail man/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing listOvmsDev@lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mail man/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing listOvmsDev@lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Sorry! Did not had time to flash. Will do it this week. Pierre Von: ovmsdev-bounces@lists.teslaclub.hk [mailto:ovmsdev-bounces@lists.teslaclub.hk] Im Auftrag von Michael Balzer Gesendet: Sonntag, 11. Dezember 2016 08:58 An: ovmsdev@lists.teslaclub.hk Betreff: Re: [Ovmsdev] OVMS v2 Memory/Settings Corruption Got the buffer overrun effect yesterday with the new release. As I now... - Keep volatile features over reset ...it now also shows up with random data in features 0-7. Annoying. Julien, Pierre, any crash debug data collected yet? Regards, Michael Am 29.11.2016 um 22:13 schrieb Julien Banchet: Thank you Michael, Will flash it this weekend! MfG, JaXX./. On Tue, Nov 29, 2016 at 10:10 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de> > wrote: Julien, Pierre, here's a firmware build with crash debug enabled: https://dexters-web.de/f/tw-beta/OVMS-Twizy-3.8.2-crashdebug.zip It excludes the diag mode (serial interface command shell) but is otherwise complete. The crash debug logs to the server (when it is/becomes available), historical record type "*-OVM-DebugCrash". These records expire after 30 days, so you can collect some days. The crash count and data from the most recent crash will also be shown by the SMS/text command "DIAG". The crash records contain a crash count, crash reasons (flags from RCON) and the last checkpoint seen before the crash. Regards, Michael Am 28.11.2016 um 22:37 schrieb Julien Banchet: Sure Michael, I've never got around compiling it right, and I'm out of a Windows since, wow, I don't even know if grub would boot the partition anymore... If you have it under hand (i hope), I'd be happy to give it a shot, it would also be the occasion for me next weekend to pull a ribbon cable out once and for all (or find a clever way to keep it hidden though programmable) How does crash recording work ? over Diag ? (PS: 50M/month data if needed) Julien ./. On Mon, Nov 28, 2016 at 10:16 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de> > wrote: There's no memory management in the module, there's too few RAM available to do dynamic allocations. All buffers are static, the error can be some pointer corruption or missing length check / end of string check. A stack overflow could also be possible, the software stack is 256 bytes (1 page). As there's not enough ROM left to support the crash debug framework anymore in the Twizy build, I cannot tell if that happens again. Julien, you could try a reduced build with crash debug recording enabled... Regards, Michael Am 28.11.2016 um 22:00 schrieb Greg D.: Ah! That sounds much more likely. Is there an error (timeout) path that might be freeing the buffer when it's still in use? Greg. Michael Balzer wrote: Hi Greg, welcome :) Juliens parameter #0 has been overwritten with "Topping o", which is part of the charge status message ("Topping off"). So it's much more likely we've got a buffer corruption bug that's triggered by (maybe) bad connectivity situations. Regards, Michael Am 28.11.2016 um 06:38 schrieb Greg D.: Hi all, New here, so this may be totally off the wall. I notice that the first example, with a "5" going to a "k", it may be more easily explained as a bit shift instead of a set of flips. Is there anywhere in the system where the bytes are clocked serially between devices, where there may be some marginal timing? Just a thought. Greg. Mark Webb-Johnson wrote: $ perl -e 'printf "%08b\n",ord("5");' 00110101 $ perl -e 'printf "%08b\n",ord("k");' 01101011 $ perl -e 'printf "%08b\n",ord("8");' 00111000 $ perl -e 'printf "%08b\n",ord("Z");' 01011010 Strange. Seems more than a simple bit flip. I haven't seen this myself, or heard of it much from other users. Is the Twizy code using EEPROM for anything other than settings storage? I know that there are a very limit number of write cycles into that EEPROM space. I did some googling, but all I can find is corruption during writing (either power down, or interrupt during write). But, for our case of very very rare EEPROM writes, that shouldn't be an issue. Regards, Mark. On 25 Nov 2016, at 5:47 AM, Michael Balzer <mailto:dexter@expeedo.de> <dexter@expeedo.de> wrote: The EEPROM data loss is a known issue, and I'm afraid there's nothing we can do about that. It seems to be a bug in the PIC18. Regards Michael Am 24.11.2016 um 22:10 schrieb Julien Banchet: Hi all, Thanks to Michaels last message to remind me to ask a question here: Since a few months, maybe a bit more because it happens only once in a while, I have noticed I wasn't receiving the SMS alerts (feature on SMSIP mode) , and sending a "Stats?" only gave me the nasty access denied answer. It turns out, using the application, I noticed that the phone number was getting corrupted (afaik, it's the only setting affected) Normally: "+33651886877 <tel:%2B33651886877> " it became "+336k1886877" or "+33651886Z77" etc... like a solar flare bit flip !_______________________________________________ _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
participants (5)
-
Greg D. -
Julien Banchet -
Mark Webb-Johnson -
Michael Balzer -
Pierre Uhl