Gevcu looses halve of the programmed data

[Elegancec]

Hi, the GEVCU has lost halve of the data (throttle settings like min max of T1 are still stored, but lost are: All digital inputs and outputs, battery voltage, torque, precharge delay. This happened now the third time and I need to reprogram the controller with the data, to go ahead whith driving.

Is this behaviour known? How can I solve it? Im driving the car since december and in happened in total three times, just occasionally.

Additionally, I can only reprogram it with some computers, but not with my android 5 phone. It doesn't find the gevcu.

[cgalpin]

When the settings are read and the checksum is invalid it resets the values. One way to verify this is what’s happening and to help alleviate the issue is to change the defaults in config.h to sane values for your vehicle, with some difference that you can identify from your normal settings but still get you home. Then when it happens again if you get these values then you know what it is.

If it is this, then I am not sure why it’s happening, but we could try change the code to re-read the settings a couple of times if the checksum is invalid before resetting the values. Maybe it’s a glitch and it will succeed on the 2nd or 3rd attempt.

hth charles

On Aug 16, 2016, at 11:50 AM, Elegancec notifications@github.com wrote:

Hi, the GEVCU has lost halve of the data (throttle settings like min max of T1 are still stored, but lost are: All digital inputs and outputs, battery voltage, torque, precharge delay. This happened now the third time and I need to reprogram the controller with the data, to go ahead whith driving.

Is this behaviour known? How can I solve it? Im driving the car since december and in happened in total three times, just occasionally.

Additionally, I can only reprogram it with some computers, but not with my android 5 phone. It doesn't find the gevcu.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/collin80/GEVCU/issues/98, or mute the thread https://github.com/notifications/unsubscribe-auth/ACtORSA0tshQV2UPeBNoJj4wR0sMDwM9ks5qgdxbgaJpZM4Jlj9R.

[neuweiler]

I experience this too from time to time and it's very annoying (usually makes me arrive late at work). I suspect that it happens when the power is cut while GEVCU is still writing a page to the EEPROM (e.g. when storing the energy consumption or changing the config and not waiting long enough to restart).

[Elegancec]

Hi Michael,

I have written the parameters into the config.h file, so if it looses the data, it will automatically restart with the preset data again. Up to now I don't have any problems.

BR

Hanno

Am 01.04.2017 um 17:00 schrieb Michael Neuweiler:

I experience this too from time to time and it's very annoying (usually makes me arrive late at work). I suspect that it happens when the power is cut while GEVCU is still writing a page to the EEPROM (e.g. when storing the energy consumption or changing the config and not waiting long enough to restart).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/collin80/GEVCU/issues/98#issuecomment-290925354, or mute the thread https://github.com/notifications/unsubscribe-auth/ALKe27Qq3La9ZW5otbhU1pJ1ifRSscnqks5rrmakgaJpZM4Jlj9R.

[collin80]

Yes, I'm still not entirely sure of why it happens. It happens sometimes seemingly randomly. It happens more to some people than others. It does seem like it must be some sort of power glitch or write while powering off. The EEPROM chip takes a long time to write (something like 7 miliiseconds) and the power taper can take longer than that. When that happens it is possible that the EEPROM would try to write while the voltage is insufficient to do so. The EEPROM is supposed to detect this as well I think but might have trouble if the write starts and then the power drops out mid way through. I've done testing to turn off the processor very rapidly if the power is dropping out. I can make it do that but I'm not entirely convinced it solves the problem. If either of you want to try you could add the below line into the setup() function in GEVCU.ino and see if it does anything:

SUPC->SUPC_SMMR = 0xA | (1<<8) | (1<<12);

The line causes the CPU to go into reset at 2.8V on the 3.3V input line. This causes it to go into reset very quickly after the power starts to die. I've looked at the power rail on drop out and with this line the voltage tapers off much more slowly after the CPU goes into reset. The CPU is the main consumer of power on the 3.3V rail ordinarily. With the line in effect it should be possible for a write issued by the CPU to go through as the power stays steady for long enough to write. But, it's kind of hard to test that thoroughly enough.

I suppose the line probably doesn't hurt anything so after some more testing I will likely add it into GEVCU for all subsequent releases.