DIYEFI.org Forum

I realised this afternoon while working through the variables and fixed point stuff that it would be extremely prudent to have flash burning functional BEFORE installing tables and writing math code that uses variables that will all need to be written. The thing is, just writing to a random location in flash is not really going to work all that well. We probably need to write blocks at a time, and we probably need a convenient way of indexing all the variables inside that block.

I know that when a struct is allocated in memory that the components inside it are stored sequentially in a single block. This could be a good way to go I guess.

Someone (me?) really needs to go through the documentation for our core and see what is involved in writing to flash, how much granularity there is available, and whether it holds up the processor in the mean time etc etc etc.

The way the vars and tuning data is stored in memory will also affect the way the serial code looks them up to send etc.

If anyone wants to grab the lead on this, feel free to get stuck in and do it.

As usual all thoughts are more than welcome.

Fred.

Good to see a FLOOD of people rushing in to help make the project a success here

Anyway, application note AN2720 contains the information required to make flash writing work.

It specifies that erasing a sector will block interrupts for ~20ms and writing a word will block them for 46us. The former will stuff everything up, and the latter will be OK if the code is written properly (not confident of that right now in this respect, but I have thought about it).

Our chip has an "abort erase" command too, SO, that could save us, but, I doubt it. Reason being, if it takes 20ms, what does it matter when you do it? When will there be a time when you can go 20ms without doing anything? There won't. So it's not a lot of use to us really.

Hence, we will have "burn stumble" if burning is performed on a running engine. The code will just have to recover gracefully from such "resets" without getting confused and pick up sync/start working again ASAP.

**********************

Because the erase takes 1024 bytes out at a time, programming one variable will cause the entire area to be rewritten from RAM. This means that the data HAS to be buffered in ram or flash to change any of it. This is OK as we would have to store all adjustable stuff in RAM anyway for runtime tuning to be possible. What it means though, is that for our burning operations to be flexible we will need to copy the parts we don't want to change up to RAM in parallel with the "working copy" or we will burn all items without that sector at the same time whether we want to or not. The consequence is that if you change 3 vars in a particular sector and burn them one by one you will erase and write that sector 3 times. If you burned them all at once you would save 2 erase/write cycles for your flash.

Hence a bit of thought needs to be put into where things live and how they are grouped and how they are burned or not burned etc. This needs to be thought of for both the firmware, comms, and front end in terms of practicality and usability either of which would be easy to compromise.

**********************

So, this is the first assembly our code will contain then! The source for both C parts and ASM parts is included in that app note so a little CW > GCC porting and we will be away laughing. Maybe.

At least I know where I stand with regards flash code now. Now it can sink in a bit and I/we can come up with some solutions.

Feel free to post yours here even if you think they are ridiculous. Even a ridiculous comment could spark some good thoughts in someone else while they think about it pros/cons and how to rebut it etc.

Fred.

I would jump in to help - but i dont have the hardware to debug - if you need just chunks of code let me know.....

Thanks for the offer, true dedication, and the reason your name is green :-)

Freescale has the code part covered. What we need are ideas for the intermediate layer between the two and a discussion of the aspects and impacts of it on front end stuff and back end stuff. Once we know what we want and can and can't do, the solution should become obvious.

Discuss first, code second = better code and less work.

Fred.

Ok just to make myself look useful -
http://osdir.com/ml/hardware.microcontr ... 00238.html
http://www.noicedebugger.com/help/68HC12.htm
http://www.noicedebugger.com/68hc12.html
http://www.abatron.ch/fileadmin/user_up ... toprog.pdf
http://www.nabble.com/Looking-for-softw ... 30439.html
http://www.toucantechnology.com/Trade%2 ... 68HC12.htm
http://www.seattlerobotics.org/encoder/ ... 8HC12.html


But before all that - check this out -
http://cml.mfk.net.pl/hc12mem/

shameem wrote:But before all that - check this out -
http://cml.mfk.net.pl/hc12mem/

I've been using it every day for months ;-)

Thanks though. Perhaps the serial monitor code has some examples of how to write to various parts. I don't think that is all that tricky though, just ensuring it is all cached in ram or other flash each time is key.

You have mail, some good news, some bad.

Fred.

I was just parsing through the hc12mem code - and here's what i found in a cursory inspection - File: hcs12mcu.c - Line: 1032

I'm not sure if you realise, but hcs12mem sends that via serial to the chip and the serial monitor code does the actual burning. That sends a write command to the chip, it doesn't write it itself. Sorry if you knew that/it was obvious.

Fred.

Yes it actually steps into file hc12lrae.c line 1200

/*
* write target FLASH
*
* in:
* file - file name with data for programming
* out:
* status code (errno-like)
*/
static int hcs12lrae_flash_write(const char *file)
{

LRAE is still a freescale program that is stored on flash on the device and works from there through serial though. I'm not certain we are understanding each other properly. I'm not certain which direction that misunderstanding is in either :-) Could be either way! lol.

Fred.