Hi Christopher,
when I switched from IDDE Version 3.0 to 3.5, I experienced a similar
problem,
though on Sharc 21161.
It was definitely caused by ADI's modification of the linker/loader
stuff.
I played a lot with modifying the ldf file and/or other settings but all
failed.
Frantically I just copied the file 161_prom.asm from Version 3.0 into the 3.5
project,
recompiled and used that instead of the one which came with the 3.5 release.
And, voila, it worked!
The only issue is that the debugger behaves differently while stepping through
the code.
But that can be fixed while in emulator session.
I guess that you suffer from the same problem, since you upgrade from a 3.0 to
a newer release.
And there HAVE been modifications which have to do with the ldf/linker/loader
stuff and
that ..._prom module, which is used during load.
I would not recommend using the old one as I did, since
- I don't know if it works with 4.0
- This has not been validated by ADI.
- I cannot explain exactly why it works.
But if nothing else helps, maybe it indicates where the solution might be
hidden...
Just my 2 cts...
Bernhard
> -----Ursprgliche Nachricht-----
> Von: Christopher Houdeshell [SMTP:choudeshell@chou...]
> Gesendet am: Dienstag, 21. Juni 2005 20:31
> An: ADSP@ADSP...
> Betreff: [adsp] 21065L & VDSP++ 4 External Flash Problems
>
> Hello all. I hope that you all can help me on this. We currently have a
> 21065L on a custom board with a 8MB Flash. We also have SDRAM. This is
> our problem. We have a small test application that blinks one of the LED
> lights. When using VDSP++ 3.0 everything works fine. Let me explain. The
> problem itself is only a few lines, just a BIT TGL on the 0th flag. In
> the LDF, when we set SEG_PMCO to reside in internal memory everything
> works fine. Along with if we set SEG_PMCO to reside in external FLASH
> memory. So, what we have is a program compiled and linked in VDSP++ 3.0
> with everything working. When we use VDSP++ 4 with the MARCH update, we
> have different results. We are using the same project (upgraded to be
> valid project in 4.0), same LDF and same kernel. Let me make a note that
> we are using a custom kernel based off of AD's kernel. We changed only
a
> few lines to account for our SDRAM, same kernel used with 3.0. When we
> compile and link our test program in VDSP++ 4, everything works well
> with using a HPUSB ICE and the DXE file. When we burn the LDR file into
> flash we have mixed results. When we set the LDF SEG_PMCO to reside in
> internal memory, 0x8198, the application works from the DSP. But once we
> set the LDF SEG_PMCO to reside in external memory, 0x20000, our
> application doesn't work. We used the disassembly and our
instructions
> are correct when used from internal. The instructions though are
> garbage, corrupt, different when we have them reside in external memory.
> Since we use VDSP4, PACKING is taken care of, so this isn't a
problem.
> It seems as http://www.dsprelated.com/groups/adsp/show/2830.php had a
> similar problem. Please note that this application works with VDSP3.0
> flawlessly. Thank you for your time and I hope that you master can
> assist me.
>
> Christopher Houdeshell
>
> RLW Inc.
> 814.867.5122 x125
> Cell: 814.777.5484
> IM: choudeshRLW
>
> << Datei: ATT00001.html >>
AW: 21065L & VDSP++ 4 External Flash Problems
Started by ●June 22, 2005
Reply by ●June 23, 20052005-06-23
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
> 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
