FreeEMS Issues - Tunix
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000261TunixFreeEMS Pluginpublic2011-09-15 10:512012-03-30 20:35
ReporterFred 
Assigned Todandruczyk 
PrioritylowSeverityminorReproducibilityalways
StatusacknowledgedResolutionsuspended 
PlatformAllOSAllOS VersionAll
Product Version0.9.24-SNAPSHOT 
Target VersionFutureFixed in Version 
FirmwareVersionunknown, updating issue to appear in roadmap
Summary0000261: Make MTX Know Flash And RAM States
DescriptionIf I adjust a table and do not burn it, kill MTX, restart MTX, the table gets pulled from RAM, but the burn button is not highlighted.

The app really needs some way of tracking what is:

 - Flash only
 - RAM only
 - RAM tunable, flash backed
 - Burned to flash or not

Likewise, if a reset occurs (either caused, or noted via resetting of counter variable), MTX should probably prompt the user to send the tune from MTX back to RAM where it was only stored to volatile memory before the reset.

This would be useful to MS stuff as well. All the data required is provided for this via the interogation interface. Marked low priority.
Steps To Reproduce
Additional InformationAnother idea that came up recently was to get the tuner to save its tune contents to disk regularly (on change or on time period) such that it can't be lost due to an app crash combined with a key off in the car. I guess this boils down to some sort of tune management functionality and the above is a prerequisite of such a thing.
TagsNo tags attached.
Relationships
Attached Files

Notes
(0000279)
dandruczyk   
2011-09-15 20:21   
AFAIK this is NOT possible, as you don't return a status that says "this locationID isn't burnt to flash.

Plus I'm not sure how I'd even get the flash vs RAM copy of something to even compare it.
(0000478)
dandruczyk   
2011-10-24 22:02   
Pending some form of statis bit available from the ECU to denote issues. Theres no way Mtx can know this on a "cold connect"
(0000943)
Fred   
2011-12-07 15:47   
Update:

Section 4.11 and 4.16 of the following temporary copy of the vanilla spec document clearly show how to know this information:

http://stuff.fredcooke.com/VanillaSerialProtocolInterface.pdf [^]

This was always true, but only documented formally recently, despite having been discussed in IRC while implementing it.

0x0002 Block Is In RAM
0x0004 Block Is In Flash
0x0010 Block Is Read Only

Are the main types.

Note, currently configurable things are either in ram and flash or just in flash, however in future there may be configurable things that are ram only and transient present too. Read only things that are in RAM are writable in BenchTest firmware too, however that is currently not useful to do. There currently isn't anything read only and in flash. It does not make sense to have things read only and in both flash and ram, at least, I don't think it does.