Reading FLASH after programming

--- In 6..., "theobee00" wrote:
> Nothing like the flash gets relocated to default on reset?
>
> Anybody likes to post the flash programming code into the files
> area when done?
>
> Might save somebody some grief, I recall at some stage there was
> a debate on encrypting/decrypting the S1-S9 stream, did that get
> posted?
>
> All sorts of general purpuse stuff that seems to be done over and
> over by everoby coming past here.

Howdy theo, I agree that there is not enough specific examples for
every little thing. I'm sure glad of that. Perhaps to make things
worse, there is not even very many examples posted which have been
translated to show specific hardware use in every type of assembler or
compiler for each target. But then I see enough examples like
"eeprom_hcs12.c" to give me the general idea to program Flash. It
seems the solution would not be to add 10 million more examples (to
cover every possible way a developer may want to do it), but instead
to sharpen our skills to spot the actual problem easier.

For example in the case here, Jeff M. is asking whether the target
really requires a reset before the Flash at 0xefff is valid. The
answer is no, whatever you write should be valid the moment the Flash
becomes readable because it's not in a programming state anymore. I
guess the second question might be "then why is my code not verifying
it correctly", or "why is NoICE reading wrong before target reset",
but we should just wait 'till he asks those so maybe he will give some
code and we can see what's wrong with it.

Forgive me for saying; I think too many examples out there actually
weaken our minds, rather than help us. We need to practice thinking in
order to be free agents. Start a New Thread

> > Both. My code does not read the correct value and this is also what
> > appears in my BDM tool (NoICE). In the code, right after the Flash was
>NoICE caches Flash ROM contents by default, you have to disable
>"cache Flash contents" when debugging Flash modifying code.

Caching of Flash is only done on the HC08 when using MON08. NoICE
uses caching there because reading memory using MON08 is so SLOOOOOW,
and it makes for a significantly nicer debugging experience.

As Oliver points out, there is a check-box in NoICE's MON08 config
dialog to disable the caching, as must be done if a user program is
burning Flash.

But caching isn't done on the HC12, MC9S12 or the MC9S08, all of which use BDM.
Best regards, John Hartman
NoICE Debugging Tools
http://www.noicedebugger.com Start a New Thread

John Hartman wrote:

> > > Both. My code does not read the correct value and this is also what
> > > appears in my BDM tool (NoICE). In the code, right after the Flash was
> >NoICE caches Flash ROM contents by default, you have to disable
> >"cache Flash contents" when debugging Flash modifying code.
>
> Caching of Flash is only done on the HC08 when using MON08. NoICE

Sorry for the wrong information (I didn't use HC12 NoICE), and thanks
for the clarification.

Oliver
--
Oliver Betz, Muenchen Start a New Thread

--- In 6..., "Jeff Smith" wrote:

> Howdy theo, I agree that there is not enough specific examples for
> every little thing. I'm sure glad of that. Perhaps to make things
> worse, there is not even very many examples posted which have been
> translated to show specific hardware use in every type of assembler or
> compiler for each target. But then I see enough examples like
> "eeprom_hcs12.c" to give me the general idea to program Flash

All right for you C types, you got all the hardware pre-chewed, us low level programmers like a sample including pitfalls to watch out for, learn a lot more then putting in a line of C.

I recall the hundred or so lines of code to program the EE took a few weeks before it was polished to my satisfaction, digging through a heap of manuals to find the few relevant lines for what you are doing is not my idea of learning things, that sort of intimate knowledge is not transferable to another chip either.

Flash and EE are particular tricky, you get it wrong and you can have problems ranging from fading bits to destroyed chips or unexpectedly hung programs when field programming.

> For example in the case here, Jeff M. is asking whether the target
> really requires a reset before the Flash at 0xefff is valid. The
> answer is no, whatever you write should be valid the moment the Flash
> becomes readable because it's not in a programming state anymore. I
> guess the second question might be "then why is my code not verifying
> it correctly", or "why is NoICE reading wrong before target reset",
> but we should just wait 'till he asks those so maybe he will give some
> code and we can see what's wrong with it.

Doesn't hurt to go through the possibilities and give him some pointers of what could go wrong, it helps a lot when you get some positive answers like yes Flash should be readable when the xyz flag comes up, you can then look for other problems.

> Forgive me for saying; I think too many examples out there actually
> weaken our minds, rather than help us. We need to practice thinking in
> order to be free agents.

As it happens I have enough problems at hand to hone my skills in all sorts of areas, adding more problems like sorting out flash programming in detail for a specific chip is overkill.

Of course I could start up a C compiler and fish out the code, but I prefer a well-commented assembler example.

Too many things to know or research, do you know for example that unusual but true,when making Hasjee you brown the meat after boiling it, or that the average run of for my roof area in Sydney is 120kL per year?

Any idea how to calculate the optimum size of a holdng tank? neither do I yet:-)
Cheers,

Theo Start a New Thread

--- In 6..., "theobee00" wrote:
> --- In 6..., "Jeff Smith"
> wrote:
[..]
> > examples like "eeprom_hcs12.c" to give me the general idea to
> > program Flash
>
> All right for you C types, you got all the hardware pre-chewed, us
> low level programmers like a sample including pitfalls to watch out
> for, learn a lot more then putting in a line of C.
>
> I recall the hundred or so lines of code to program the EE took a
> few weeks before it was polished to my satisfaction, digging
> through a heap of manuals to find the few relevant lines for what
> you are doing is not my idea of learning things, that sort of
> intimate knowledge is not transferable to another chip either.
>
> Flash and EE are particular tricky, you get it wrong and you can
> have problems ranging from fading bits to destroyed chips or
> unexpectedly hung programs when field programming.

You'll be happy to know that I found my example, and it's in Asm.
It demonstrates the trouble I mentioned with finding the right
example. Unfortunately it does not calculate ECLKDIV/FCLKDIV. My
comment however indicates 16 MHz xtal.

>
> Doesn't hurt to go through the possibilities and give him some
> pointers of what could go wrong, it helps a lot when you get some
> positive answers like yes Flash should be readable when the xyz
> flag comes up, you can then look for other problems.

Here's a possible problem... make sure the debugger and whatever also
does not try to read from flash before programming is complete
(i.e. breakpoints cause update of debug views which could try to
read the flash).

I'd agree it doesn't hurt, though often it adds confusion with
too many guesses in different directions, and makes dificult
reading to find what the problem really was or if it was even
solved.

> > Forgive me for saying; I think too many examples out there
> > actually weaken our minds, rather than help us. We need to
> > practice thinking in order to be free agents.
>
> As it happens I have enough problems at hand to hone my skills in
> all sorts of areas, adding more problems like sorting out flash
> programming in detail for a specific chip is overkill.

Maybe you'd be surprised what your brain can do, but then I know
you well enough... You have a sharp mind. What I'm saying implies
that the developers working in Assembly develop more ability. I do
believe that if one can follow Asm then one can certainly follow C.
Personally I cannot work in C (embedded) without also being
skilled in Asm.

> Of course I could start up a C compiler and fish out the code, but
> I prefer a well-commented assembler example.

I didn't mean to imply anything about specific language by noting
that C source, but more specific examples are better detailed in
Asm. That is why I'm happy that I found my eeprom example. Problem
is my other point... it proves writing to EEPROM on the
DP256/DG128B, etc. but what about other targets or what about
writing to Flash at 0xefff ? I don't remember if I've done that
yet, but this could be modified for it.

> Too many things to know or research, do you know for example that
> unusual but true,when making Hasjee you brown the meat after
> boiling it, or that the average run of for my roof area in Sydney
> is 120kL per year?

My point proven--you've got it going :)

> Any idea how to calculate the optimum size of a holdng tank?
> neither do I yet:-)

Well that's what discussion forums are for, right?
My Example:
http://groups.yahoo.com/group/68HC12/files/EEPROM_HCS12/ee.asm Start a New Thread

--- In 6..., "Jeff Smith" wrote:
[...]
> My Example:
> http://groups.yahoo.com/group/68HC12/files/EEPROM_HCS12/ee.asm
>

Oh, I forgot to write some details about this:
- By default the command is "verify blank"
- tested on MC9S12DG128B
- does not un-protect the EEPROM before attempting anything
- I mentioned, but does not calculate ECLKDIV (make sure it's right)

If I get time, I'll update it. Maybe it should unprotect EEPROM first,
and the default action should be "write word". Start a New Thread

--- In 6..., "Jeff Smith" wrote:

> You'll be happy to know that I found my example, and it's in Asm.
> It demonstrates the trouble I mentioned with finding the right
> example. Unfortunately it does not calculate ECLKDIV/FCLKDIV. My
> comment however indicates 16 MHz xtal.

Indeed, earlier on I posted my EE routines, they include a sorter to allow programming random bytes, words and double words, even across boundaries.

They can be found under theobee together with other material that can be handy or not, but I do habitually comment on items that can be a trap for the unwary (to remind myself mainly) including timings and pitfalls, as well as pointers to manuals I found that relate

Needles to say it is far from comprehensive and contains a fair swag of leftover 6800 code.

> Here's a possible problem... make sure the debugger and whatever also
> does not try to read from flash before programming is complete
> (i.e. breakpoints cause update of debug views which could try to
> read the flash).

It is a knotty problem, on the one hand you do not want to hang around till the programming is complete and thus halt other operations, OTOH you have to prevent inappropriate reads and writes, more flags to check, (semaphores for our marine trained friends)

> > > Forgive me for saying; I think too many examples out there
> > > actually weaken our minds,

Was it Keats who said the flesh is willing but the mind is weak?

> Personally I cannot work in C (embedded) without also being
> skilled in Asm.

Reading this newsgroup for a while it seems a common problem, students are thrown into C and have all sorts of problems because they don't understand the underlying hardware, a few samples are very handy.
John Hartman gave me the OK to use some of his serial routines linking to his NOICE, it was a great help to get a start understanding what the new (for me) instructions did, OTOH it caused some grief as well since it seems originally written for a Z80 or some such, had to swap a lot of the endiansJ.

> > Of course I could start up a C compiler and fish out the code, but
> > I prefer a well-commented assembler example.

> DP256/DG128B, etc. but what about other targets or what about
> writing to Flash at 0xefff ? I don't remember if I've done that
> yet, but this could be modified for it.
The little monitor I wrote as the basis for my debugging software checks the incoming data for destination and calls the appropriate routine, Ram, EE, flash etc, although the hooks are there I have no plans to allow field upgrades and so have not needed to finalise the flash routines.

> My point proven--you've got it going :)

Blush.

> Well that's what discussion forums are for, right?

Haven't found a group to discuss optimum size of rain water tanks yet, it is actually a difficult one to solve, with a bit of effort you can get data on average rain fall at least close to your area, that's well and good if you have unlimited storage, but for ordinary situations you have to get data on rainfalls peaks as well as usage to even take a guess at it, Sydney has a nasty habit of occasionally dumping the average monthly rainfall in ten minutes, to do a cost benefit calc is not trivial.

> My Example:
> http://groups.yahoo.com/group/68HC12/files/EEPROM_HCS12/ee.asm

Good effort, anybody has the same for flash?

Cheers,

Theo Start a New Thread

--- In 6..., "Jeff Smith" wrote:

> - does not un-protect the EEPROM before attempting anything
> - I mentioned, but does not calculate ECLKDIV (make sure it's right)
>
> If I get time, I'll update it. Maybe it should unprotect EEPROM first,
> and the default action should be "write word".

Another difficult one, it is probably not a good idea to have an unprotect command as part of any write routine, you protect it from writing in the first place to keep data secure.

Cheers,

Theo Start a New Thread

--- In 6..., "theobee00" wrote:
> Another difficult one, it is probably not a good idea to have an
> unprotect command as part of any write routine, you protect it
> from writing in the first place to keep data secure.
>
> Cheers,
>
> Theo

Right, so it could be two examples. One demonstrates "unprotect", and
the other demonstrates "write". I did decide that I wasn't going to
make this eeprom example unprotect first, partly because I'm having a
hard time understanding how one should handle things. Certain EPROT
register bits supposedly can be written to enable protection only, not
to unprotect.

The problem with EPROT is that it says EPOPEN and EPDIS can enable
protection but NOT be written to unprotect. So when it is protected by
one of those in eeprom (retained on powerup), it claims NO method of
unprotecting it because of course you cannot write nor erase eeprom
when it is protected. (:-|

If only I had some examples to see how to make my example...
=== [DG128B] EETS2K Block User Guide V01.05, pg 18 ==
All bits in the EPROT register are readable. Bits NV[6:4] are not
writable. The EPOPEN and EPDIS bits in the EPROT register can only
be written to the protected state (i.e. 0). The EP[2:0] bits can be
written anytime until bit EPDIS is cleared. If the EPOPEN bit is
cleared, then the state of the EPDIS and EP[2:0] bits is
irrelevant.

To change the EEPROM protection that will be loaded on reset, the
upper sector of EEPROM must first be unprotected, then the EEPROM
Protect byte located at address $_7FD must be written to.

A protected EEPROM sector is disabled by the EPDIS bit while the
size of the protected sector is defined by the EP bits in the EPROT
register.

Trying to alter any of the protected areas will result in a protect
violation error and bit PVIOL will be set in the ESTAT register. A
mass erase of a whole EEPROM block is only possible when protection
is fully disabled by setting the EPOPEN and EPDIS bits. An attempt
to mass erase an EEPROM block while protection is enabled will set
the PVIOL flag in the ESTAT register.
=== Start a New Thread

--- In 6..., "theobee00" wrote:
> Indeed, earlier on I posted my EE routines, they include a sorter
> to allow programming random bytes, words and double words, even
> across boundaries.
>
> They can be found under theobee together with other material that
> can be handy or not, but I do habitually comment on items that can
> be a trap for the unwary (to remind myself mainly) including
> timings and pitfalls, as well as pointers to manuals I found that
> relate

[theo, you already know this, but I add it for newbies:]

I have much of that too. but don't get them confused. There's a
difference between people looking for an "example", or looking for
"libraries". The example just demonstrates what it is an example of.
It is mostly not reusable but is meant to teach simple concept. The
library collection is an implementation, meant to be reusable, and
normally intends to fit any general use imagined. Because of that, the
library functions which handle writing to every type of memory and any
boundary transparently are terrible examples for learning.

In order to conciously learn a thing, you should first know what it is
you wish to learn. Start a New Thread