I have an idea. What do you guys think about adding a log/counter to the tuner program so that it keeps track of how many times a flash address has been burned?
We could also have an internal counter as well, so that it can send logs to the tuner program the next time it's connected? If the firmware has the ability to burn itself.
Or am I way off base ?
-sean
Flash Cycle Tracking
- SleepyKeys
- LQFP144 - On Top Of The Game
- Posts: 549
- Joined: Mon Feb 11, 2008 10:52 pm
- Location: Arizona
- Contact:
Flash Cycle Tracking
You snooze, you lose!
Re: Flash Cycle Tracking
Sounds like a good idea to me. Although perhaps Fred is right and we should focus on the basics at first.
Is that an idea your able to write code for?
Is that an idea your able to write code for?
- SleepyKeys
- LQFP144 - On Top Of The Game
- Posts: 549
- Joined: Mon Feb 11, 2008 10:52 pm
- Location: Arizona
- Contact:
Re: Flash Cycle Tracking
He is right, no rush, just an idea that came to mind.jharvey wrote:Sounds like a good idea to me. Although perhaps Fred is right and we should focus on the basics at first.
Is that an idea your able to write code for?
Probably, its actually pretty simple.
You snooze, you lose!
Re: Flash Cycle Tracking
Fantastic idea :-)
We can just dedicate 16 bits or 32 bits to the end of each block to record the burn count in. Of course updating firmware will blow it away, so you would want to have some mechanism to save it outside the device before a firmware upgrade, or perhaps include that as a build requirement when you build a new firmware :
etc.
Fred.
We can just dedicate 16 bits or 32 bits to the end of each block to record the burn count in. Of course updating firmware will blow it away, so you would want to have some mechanism to save it outside the device before a firmware upgrade, or perhaps include that as a build requirement when you build a new firmware :
Code: Select all
#define currentBurnCount 3456 // please set this number to one higher than your current count such that the firmware burn is included, thanks.
Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Re: Flash Cycle Tracking
Rather than do this in the flash itself, perhaps we should keep a small datamap with an unsigned long per 1k block in the eeprom? The eeprom is fine with being rewritten regularly and that way we keep full flash space available (which is fairly critical for the tables for example).
I guess I just thought up another block of work for Sean ;-)
(ie create some eeprom burning functions, i'll throw up a task for it now)
Fred.
I guess I just thought up another block of work for Sean ;-)
(ie create some eeprom burning functions, i'll throw up a task for it now)
Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!