Flash Burning - what do we need to do?

[Fred]

Most live tuned EMS's interrogate the serial port for the current values required. These values are then put into memory (if the value does not come from the serial port then the internal memory values are used, normally you can then tell it to flash the tune, which sends the whole tune to the cpu which writes it to flash.

I think you have that a bit backwards. What I intend to do is have the stored tune in flash, the values being used in ram (copied up at boot time). The tuning tool will send changes in tune to the device which will store them in memory immediately. If/when the user chooses to save them to flash, they will send a command down the serial line saying "write <this part of> your tune to flash now please" at which point it will become non volatile and flash will match ram again.

Polling the PC for data constantly seems like a very bad idea, I don't think MS does it that way and I doubt other manufacturers do either. The ECU should be reactive to commands, not proactive. Listen for requests, not ask for information etc.

This generally results in several stumbles as the cpu is writing to flash.

Ours will stumble too. I forget the figures, but long enough to not know where the engine is at and not be able to fire ignition for a revolution or two.

Since i believe we're going to have a permanent connection to battery with FreeEMS?? I'm assuming you could have a question when the key is turned off sent via serial to ask if the tune should be flashed....thus the car isn't running and hence no stumbles.

That's a nice idea. I'll keep that in mind.

Fred.

[SleepyKeys]

I have just about finished my erase function. There seems to be a glitch that causes the mcu to hang when done. I'm sure it's something minor that I over looked. Not to worry I should have it done soon. I'll keep you guys updated.

Thanks,
Sean

[Fred]

A 5er says you aren't re-enabling interrupts afterwards?

[Delta]

Most live tuned EMS's interrogate the serial port for the current values required. These values are then put into memory (if the value does not come from the serial port then the internal memory values are used, normally you can then tell it to flash the tune, which sends the whole tune to the cpu which writes it to flash.

I think you have that a bit backwards. What I intend to do is have the stored tune in flash, the values being used in ram (copied up at boot time). The tuning tool will send changes in tune to the device which will store them in memory immediately. If/when the user chooses to save them to flash, they will send a command down the serial line saying "write <this part of> your tune to flash now please" at which point it will become non volatile and flash will match ram again.

Polling the PC for data constantly seems like a very bad idea, I don't think MS does it that way and I doubt other manufacturers do either. The ECU should be reactive to commands, not proactive. Listen for requests, not ask for information etc.

Unfortunately its not backwards, aftermarket ecu's function that way - so you can load an entire tune on the fly and not have to send the entire tune immediately to the ecu (which would also cause a stumble). If you've ever noticed on a Motec or Autronic, the serial port is sending data the whole time you are tuning it both ways. If you load up and it asks you if you want to download the tune to the pc and you say no - and you have a completely different tune in the software open....it immediately changes over to that tune - and if you disconnect without flashing - it immediately goes back.

[Fred]

Unfortunately its not backwards, aftermarket ecu's function that way - so you can load an entire tune on the fly and not have to send the entire tune immediately to the ecu (which would also cause a stumble). If you've ever noticed on a Motec or Autronic, the serial port is sending data the whole time you are tuning it both ways. If you load up and it asks you if you want to download the tune to the pc and you say no - and you have a completely different tune in the software open....it immediately changes over to that tune - and if you disconnect without flashing - it immediately goes back.

Do you know this for a fact (as in, from instructions or docs or seeing their code etc) or are inferring it from the behaviour?

If the latter, constant data is fairly normal. eg MT is constantly saying "whats going on in there" to MS which responds with "data is : 01000110101011". The same front end behaviour could be had by the tool reading the tune out comparing it, asking you what you want and then sending the new stuff back in. The box doesn't have to and shouldn't control that flow, but they could do it for some reason I guess. After all, they are targeted at a very different audience to the diy crowd.

Do you have more info on this?

Fred.

[SleepyKeys]

I do believe I over looked something in my flashinit(); Stay tuned.


-sean

[Fred]

Looking forward to it :-)

[SleepyKeys]

Found some mistakes.

Word of advice, always check any reference material with the official XDP user guide(especially if you area noob like me). Too many people out there seem to post things they dont know much about.

-sean

[Fred]

Word of advice, always check any reference material with the official XDP user guide(especially if you area noob like me). Too many people out there seem to post things they dont know much about.

Good advice, I found the same thing when I was learning about it. The trouble is the advice was OK when it was an HC11 core, but not now when things have changed ;-)

[SleepyKeys]

Not to worry still working on the flash code! Getting closer everyday. I'm taking the 'better to under stand every operation fully' than just sloping something together. This should give us great flexibility such as eliminating the need for the hcs12mem tool(not that is isn't a nice piece of software). Thanks for your patience.

-sean