Hi, Christopher.
> Hello. When we switched from 3.0 to 3.5, we have
memory issues.
So did I.
> So after we returned to 3.0 we are trying 4.0 .
Why did you switch back? Did you ever solve the memory issues?
If not, why did you think they should have gone away??
> To be honest, 4.0 is not looking good.
Why?
> We are using a custom kernel from 2.0 which has
worked with 3.0 and 3.5 .
What is this? A VDK kernel? RT kernel?
> So far AD has not been very helpful. I am not sure
where the problem lays.
Is it a binary kernel, or did you recompile the sources on the new version?
> Stepping through our code is horrid since 4.0
stepping functionality doesn't
> work as the same if you 'run' the program.
That's the sort of problem which I referred to:
handling of SDRAM layouts in debugging mode is different from that in run
mode.
I discussed this with ADI support (PR24616) in June last year.
Here's the interesting part of the 'approach' from ADI:
----------------------------
...
bh: I'd expected the IDDE to do this, because I set the switch "Auto
configure
external memory".
bh: In 3.0 ipack=0 were doing fine, while setting ipack to another value would
cause failure.
ADI: The IDDE attempts to do this, however, there is no fixed map which tell it
how
ADI: to configure the memory. When the IDDE downloads a 48 bit section,
ADI: the emulator knows the user has hardware which supports 48 bit packing.
ADI: When the IDDE downloads the 32 bit PM section, it knows to use 32 bit
packing.
ADI: It does not know when to switch between the modes.
bh: Therefore I used the 161_prom.dxe to activate SDRAM before loading the
program from Flash.
bh: However, in Debug mode I left it over to IDDE 3.0 which activated SDRAM
accordingly.
ADI: In the 3.0 tools, if the "auto configure SDRAM" was set, all
loads were
done as 32 bit,
ADI: otherwise, the user was responsible for setting the IPACK bits.
ADI: This is also the case when using an emulator; in 3.0, the user was resp
onsible
ADI: for setting the ipack bits. In 3.5, the LDF accurately describes the
sections,
ADI: and the emulator has enough information to set the IPACK bits based on
that section.
ADI: However, it does not know or keep track of what sections have been setup
for which mode,
ADI: and have the ability to change them back when you view them.
...
---------------------------------
If that makes some sense to your problem, tell me!
> I have read anything and
> everything that I could and I still cannot place my finger on the
problem.
Make sure you have checked the latest "Anomalies list" for both,
processor and
tools issues.
> If this does not work out by the end of this week,
I will suggest we stick
with
> 3.0 as I have been working on this problem for the
last 4 weeks.
Come on, what's four weeks?? It took me almost half a year hunting a bug
which
led to
interrupt losses which left the program hanging. Meanwhile the issue is in the
anomalies list,
and the newer tools repair it. But, alas, that's life!
If you working with a VDK kernel, or intend to, it would strongly disencourage
you to switch back,
since the 3.0 VDK has lots of really nasty issues/bugs which have been solved
in the newer releases.
If your custom kernel doesn't use the newer features nor new processors,
I'd
keep the old environment
at least for that project, as you propose.
However, if you can afford the time: it's certainly an advantage if you get
your system running
on both versions, since there's a chance that you not only hunt ADI's
bugs, but
your own as well...
>
> Christopher Houdeshell
>
Bernhard Holzmayer
Institut Dr. Foerster GmbH & Co. KG
In Laisen 70
D-72766 Reutlingen
---
mailto:Holzmayer.Bernhard@Holz...
http://www.foerstergroup.de