1. Home
  2. Embedded Programming
  3. suspicious RAM problems - mvo

suspicious RAM problems - mvo

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
Reply to
Mark
Loading thread data ...

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

Reply to
Gene S. Berkowitz

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

Cheers

Reply to
Vic

:> 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

Reply to
John Eaton

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_PAGE=18.

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

Reply to
Mark

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.