Mantis Bug Tracker

View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000459TunixFreeEMS Pluginpublic2011-12-02 13:172011-12-03 14:25
ReporterFred 
Assigned ToFred 
PrioritynormalSeverityminorReproducibilityrandom
StatusclosedResolutionfixed 
PlatformAllOSAllOS VersionAll
Product Version0.9.24-SNAPSHOT 
Target Version0.9.24Fixed in Version0.9.24-SNAPSHOT 
Summary0000459: ECU Status Window Seems To Lag Reality
DescriptionI added a bug to the bench test module on purpose (sleep 200 micros on the final iteration) to force overruns to test some new firmware code and mtx at the same time. The counter increases in the Runtime Vars window, but the flag doesn't show up. Then you do some other stuff and it does, then you clear it and it doesn't seem to clear (though I'm pretty sure the clear is working on both sides of the line) until you do some more things and it magically clears. Hence the term "lag". I don't understand it, but perhaps you do. Likely related to the recent changes, I guess. Attaching C file for you to build similarly broken firmware, though you could do the same thing with your working JimStim and some high RPMs :-)
Additional InformationMy settings for a high CPU activity bench test were, in order:

255
65535
100
std events
1111,2222,3333,4444,5555,6666 durations

If you use that file, and those settings, with datalog streaming off or on, and request a read of the full memory from the ve table tab or similar, you should get some overruns happening and be able to test this easily. MTX does retries properly when overruns happen, which is good news :-)
TagsNo tags attached.
FirmwareVersion
Attached Filesc file icon BenchTest.c [^] (5,814 bytes) 2011-12-02 13:17

- Relationships

-  Notes
(0000867)
dandruczyk (viewer)
2011-12-02 20:04
edited on: 2011-12-02 20:05

Due to decoupling datalog stream handling from status, the status window updates at a much slower rate, about half the rate set to the runtime text window currently , so if you set that to max (currently 40), the status window will update a max of 20x/second.

The issue may be that the status window updates uses only the LATEST values from the datalog stream . It DOES NOT test against anything in between now and whatever the last runs was (as there's likely to be a lot of datalog blocks that came in between the last run and now.)

So if you have status's that are going on and off rapidly its possible/likely that the status window won't necessarily show it as you expect it to, due to the decoupling.

User avatar (0000868)
Fred (administrator)
2011-12-02 20:11

That's good to know, but kind of expected behaviour, and not what I'm seeing. The overrun flag should show up and not go away until reset or counter clear call. It never shows up, well, not for a long time, and I can't tell you exactly when/how it does, though it may have been triggered by another action in another tab like read all data? Just grasping at straws, though. Same happens post reset or clear counters call in reverse. If you don't do anything else it seems to never update. I hope this helps, but I can't promise that it's accurate 100%.
(0000869)
dandruczyk (viewer)
2011-12-02 20:46

hmm, I think I know what may be causing that..
(0000870)
dandruczyk (viewer)
2011-12-02 20:55

Should be fixed in: f2fb286ea8e36c738d6e12266c6fff4d6febd050
User avatar (0000873)
Fred (administrator)
2011-12-02 21:22

Sadly no, seems unchanged, even did an autogen so that the hash in the title bar agreed with git and I could be un-paranoid. On: f2fb286ea8e36c738d6e12266c6fff4d6febd050
(0000875)
dandruczyk (viewer)
2011-12-02 21:25

provide detailed info on how to make it generate errors. (you submitted a .c file with little to no instructions on what exactly to do with it.) IS the .c file something independant or something to be dropped over a stock firmware file?

You might want to create a "broken" firmware specifically for testing things like this in the tuner.
User avatar (0000879)
Fred (administrator)
2011-12-02 21:38

Instructions are already written in the issue/additional info. Drop the c file over the top of the one with the same name replacing it and observe a two line diff, one header include and one sleep call. if you run a high frequency bench test and query the ecu data with the get data from ecu button, it will generate overruns on demand. The same can be done with high rpm input from jimstim, but not me, mine's fucked. You could also set the pattern wrong for the decoder type and generate sync losses by turning the js on and off. You don't need the c file for these alternative methods. There may be others too.
(0000887)
dandruczyk (viewer)
2011-12-03 12:38

Fixed for real this time in hash a3978679d6155ebc1cbce545d5fda115e7c85ebb
User avatar (0000889)
Fred (administrator)
2011-12-03 14:25

Confirmed fixed!


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker