flashforth-devel

[Flashforth-devel] Pic18 change system protection addresses?

[craig b. <dab...@ya...>]

I've built one of our in-house tools around a PIC 18F46K22 and FlashForth 5.0 just because I think a smart user should be able to tweak their tool to do what they want it to do.  This actually hasn't worked out badly except that I'm now getting the occasional complaint that whenever they have to fully re-load the programs for whatever reason; they have to replace the calibration numbers that were stored in eeprom.  (They get re-initialized when declared as eeprom "value".)  I completely understand and agree with the design decisions that led to ram and eeprom "here" pointers only being reset by an "empty" and not by "forget", but I need a work-around of some sort for this problem.

My first and worst idea was to put all of the ram and eeprom allocations at the start (like cobol) and then just use "forget" with a marker after them.  The snag is that anything after that point that allocates memory other that flash will have to be separated out and moved to the top and the marker moved.  Messy, clumsy, and prone to error when trying to maintain.

The next thought was to still use the "empty" but start the load off by checking the eeprom "here" address to see whether the location was initialized or blank.  If blank, the eeprom values could be assigned and allocated normally.  If already initialized, the named could be re-established using a variant of "value" that just didn't store anything to the locations.  Once done with that the clean re-load could proceed normally.

What seems the best approach to me would be a word that could be invoked after the driver extensions and calibration allocations were loaded the first time that would update the default pointers to make them part of the base protected system.  A hex image could then be saved for programming a new chip and the old one could have as many reloads as it could stand without unnecessary re-calibration.

So, have I analyzed the problem correctly?  How many things would I need to chase down in the disassembly to change the system self-defense?  The final state of the pointers and where they get their power-up initializations from aren't obvious to me from reading the assembler code, but I know they have to be there.

Thanks for your time and any thoughts you might have on this matter,
Craig Bair, binary behaviorist

Re: [Flashforth-devel] Pic18 change system protection addresses?

[Mikael N. <mik...@fl...>]

I think your analysis is fine, but what to do about it ?

The protect system is hardcoded so you cannot circumvent it without
changing the FF kernel.

I have never tried dumping FF from a chip an reprogramming the image.
I quess you can poke in the numbers to the hex image after the dumping 
it out.

Look for STARTV: in the source. There you have 6 words that is used by 
EMPTY.

;;; EMPTY dictionary data
STARTV: dw      h'0000'
DPC:    dw      dpcode     ; dp_user_dictionary
DPE:    dw      dpeeprom
DPD:    dw      dpdata+h'f000'
LW:     dw      lastword
STAT:   dw      DOTSTATUS

I quess you can get a map or listing file to tell you the addresses.
The data you need to move there is the first 6 words in eeprom.

Or a kernel word SNAP could be contructed to set the pointers used by 
EMPTY.
Those could also be stored in eeprom. (Just because I dont like to write 
to kernel flash.

And have another word TRULYEMPTY that works like the EMPTY of today.

Or make a word ALMOSTEMPTY that gets you back to the SNAP status.

Actually it not that simple... The kernel and the user words are in 
separate lists.
So FORGET would anyway be able to forget all user dictionary words.
FORGET would need to check that does not forget below the SNAPped 
dictionary pointer.



------------

But the above is almost the same as defining marker

eeprom 0 value bla
marker calibration
: blu . ... ;
marker basicwords
: asdf ;
marker appwords
: akajshdk ;

59 to bla

except it requires some discipline, that you don't actually use EMPTY.
Changing EMPTY to some random string would fix that :-)

Since the values already exist in the dictionary,
reinitialization of the values will be skipped if you send a file
to FF.

So the fast solution is to have the special values defined in the start 
of the dictionary
  + marker, just as you suggest.

No need to mess with forget. Using forget will always mess up the 
system.


-----------

You could create another type of defining word called

cal: ( address 'name' -- ) // define a uninitialized value at address.
: cal: flash create -2 dp +! i, ram does> @ ;

Modify this row in the FF source code
DPE:    dw      dpeeprom

by increasing the number protected EEPROM words (dpeeprom + EXTRA)
There you can use as EXTRA number of bytes starting at $ec0c for 
unforgettable calibration data :-)

Or just use adresses at end of eeprom or end of flash, and hope no one 
ever allots that far.


hex  ok<$,ram>
ec50 cal: cal1  ok<$,ram>
cal1  ok<$,ram>ffff
45 to cal1  ok<$,ram>ffff
cal1  ok<$,ram>ffff 45
ec50 @  ok<$,ram>ffff 45 45

So now your cal: values always uses TO to init  the values.

BR Mikael