suspicious RAM problems - mvo

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View

Hi group,

My company is doubting my applications; there are happening strange things
in the field. It's about terminal running a state-machine on an old H8/500
processor. The problems seems to be weird and like this.

When we write software in the terminal's flash it runs differently from
terminals that have another software-version pre-loaded. In both situations
the previous software has to be overloaded fully (well, thats what is
desired). A lot of people are 'against' us saying the previous version
affects the new version.

A guy made a loading sequence with functions copied to (and running from)
RAM (still don't get how you do that trick, with the source-code in front of
me but whatever). But I want to clear the RAM chip (512K) totally, first.

Any tips on how to check the size of the RAM-chip? (the tricky-part:) We use
hardware with both 256K and 512K RAM.

Some tips would be appreciated very much!

Best regards,
M/\RK

--

M/\RK



Re: suspicious RAM problems - mvo
snipped-for-privacy@gmx.net says...
Quoted text here. Click to load it

First, depending on how memory is mapped, it won't matter if you just
assume that the RAM is always 512K.  If the last address line isn't
connected on the smaller 256K RAM, you would simply erase it "twice".
Even if the flash were mapped to the address immediately after the RAM,
it would not matter, as a RAM write will not affect the flash data.

Does the loader fully erase the flash?  Has anyone checked that the
erase is being performed properly?

Have you tried to reproduce this (use a "pre-loaded" part, then
install your new version, and let it run)?

--Gene





Re: suspicious RAM problems - mvo
: snipped-for-privacy@gmx.net says...

:> My company is doubting my applications; there are happening strange things
:> in the field. It's about terminal running a state-machine on an old H8/500
:> processor. The problems seems to be weird and like this.
:>
:> When we write software in the terminal's flash it runs differently from
:> terminals that have another software-version pre-loaded. In both situations
:> the previous software has to be overloaded fully (well, thats what is
:> desired). A lot of people are 'against' us saying the previous version
:> affects the new version.
:>
How "old" is old? A lot of the lifetime estimates for early eprom/flash parts
were only guesses. There was a lot of concern that after ten years a lot of
things would start getting electronic amnesia.


John Eaton

Re: suspicious RAM problems - mvo
Hi,
some address may or not be: read, any transform(+1 for instance),
write, read again. Adr exist if value is waited.

Cheers

Re: suspicious RAM problems - mvo
Many, many thanks to all that replied! I've got the problem solved.

There where these three little defines I didn't know the meaning of.
They where added to the linker file with option -D. That stands for a
'normal' #define, like in the c-source-code. I was wondering what they
where for because they where stated like this: -DSTACK_PAGE18%.

Well... now everybody in this group knows; it corrupts my tests haha.

When I commented the defines in the linker-file I got error's for not
defining them before using them in some .r21 and .r03 files. For
instance the .r21 is an assembly-file. The .r03 had to do with
cstartup. They are all in the IAR (compiler) directory and like I
guessed after that... have to be set carefully because they
influence/set segments. There was a -DSTACK_PAGE and a -DDATA_PAGE. I
did't wnat to go into the whole assembly... but it cleared up enough
for me.

Thanks again all!

Mark

Site Timeline