I've had GPS streaming enabled during the last days, and neither GPS
nor GSM connectivity are good at the moment. May be related, as
streaming means more data communication. But still that should not
lead to RAM corruption.
Am 14.04.2013 17:54, schrieb Michael
Balzer:
Mark,
I've got the last but one version in my car, just lacking the new
VEHICLE commands.
I've got two open issues, the minor one being to raise the 12V
auto acquisition time even more, as the faults have become better
but it's not yet perfect. I'm trying 20 TAD now, as we don't need
to be fast on that A/D conversion.
But a major issue might have turned up: I've just had the second
RAM corruption within three days. Effect:
MP-0 c32,0,106,119,*-OVM-DebugCrash,2013-04-14
14:06:40,0,2.2.7/RT2.6.4/V2,0,0000,20
MP-0 c32,0,107,119,*-OVM-DebugCrash,2013-04-14
14:25:13,0,2.2.7/RT2.6.4/V2,80,0020,61
As there is no checkpoint 61, this means at least the debug
variables have been overwritten, was the same with the first
occurence (but other values).
As the module behaves weird afterwards I suppose more variables
have been corrupted.
I've looked through the last changes several times, I'm pretty
sure none could have introduced this kind of bug... if I'm the
only one experiencing this, maybe I've got some hardware issue as
well?
I'll continue checking the source for possible buffer overruns...
Regards,
Michael
Am 14.04.2013 16:29, schrieb Mark
Webb-Johnson:
I've just built from latest sources, v2.3.1. This is a release
candidate, and I have 24 hours to test before i need to send it
to China.
It is in my car now, and seems ok. I'll do more testing
tomorrow.
I'd be grateful if others could grab it and put it in their
cars to ensure there are no major problems.
Regards, Mark.
All seems ok.
I've committed and pushed my changes (just the
stp_ltf_h() function, and change to report cac as
999.99 to server).
I've just flashed and it will go in my car
tomorrow.
Regards, Mark
Mark,
I just checked in my latest changes.
In net.c I added the pending send check also to the
new net_notify_errorcode send, I think that should be
correct, but please have a look.
I saw the new stp_f() function, but I don't understand
it's purpose yet. What's the difference to my
stp_l2f() function?
Btw: l2f = "long to float" -- I think "_f" should be
reserved for an stp call with a real float type
parameter, if we once really need one.
Regards,
Michael
Am 12.04.2013 20:16,
schrieb Michael Balzer:
Nikki,
yes, see attachment.
I could not make out any possible source of that
strange error I had yesterday (completely garbled
data).
I made a clean build with a freshly started MPLAB
and got no errors up to now.
May have been something completely different, not
related to my last changes.
Regards,
Michael
Am 12.04.2013 17:01,
schrieb Nikki Gordon-Bloomfield:
Michael,
Any new firmware for me to test this
weekend?
Nikki.
I
think I was a bit too fast on this, Nikki,
don't use that version, it seems to have
some new bug causing frequent crashes...
:-(
Regards,
Michael
Am 11.04.2013
19:22, schrieb Michael Balzer:
Mark, Nikki,
I'm currently trying to fix a last bug
with the power statistics (the distance
counter still went wrong), and I'm
trying to get the 12V A/D conversion to
work without these strange "peaks" by
raising the automatic acquisition time.
I will finish testing this ASAP or tell
you in time before sunday.
Nikki, I attached the latest version in
case you'd like to test as well.
Regards,
Michael
Am 11.04.2013 16:41, schrieb Mark
Webb-Johnson:
China is bugging
me for final firmware for the next
batch of hardware. I need to get them
this early next week.
I've committed what I need for the
Tesla Roadster (and framework). Last
outstanding small change to make is to
send CAC as 999.99, rather than the
current 99999, using Tom's new library
function.
Michael B & J: can you check
Twizzy and Volt/Ampera, to see if
everything is ok with current firmware
or there is anything you need changed?
I plan to cut release candidate for
2.3.1 on Sunday.
Regards, Mark.
_______________________________________________
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 * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * 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 * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
--
Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
<dexter.vcf>
_______________________________________________
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
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
--
Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
--
Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26