DSPRelated.com
Forums

21065L & VDSP++ 4 External Flash Problems

Started by Christopher Houdeshell June 21, 2005

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

 



Hi Christopher,

> I have traced the problem down to one line though. When it pulls the
> instructions out of our FLASH it places them in the PX register. The
> line that I am having trouble with is sad... PM(I8,M14)=PX
> That should place whatever is in PX into program memory at location I8
> then increment I8, M14 times...or 1 in this case. Any light?

Have a look into the manual. If you move from/to the PX register,
the result depends on some register settings:
- IPACK
- SIMD
- link data pins' configuration
- source/destination of instruction
It can copy 16,32,40,48 or even 64bits with a single instruction!

In your case you're likely to transfer 48bit data (code is 48 bit, usually).
So, what happens depends on the flash memory width/access mode.
If this is logically 48bit wide, it still depends how it is arranged.
But this has to do with the not shown fill command (PX=...)
For the PM(...)=PX, it depends on the destination:
If internal memory is accessed, you should not have problems.
If external memory is accessed, the pack bits for that region should be
evaluated and the access mode must be derived accordingly.
Settings of I8,M14, and the IPACK bits should be checked.

One thing which has obviously changed since 3.0, is the evaluation of the
IPACK bits.
While they have been mostly ignored in 3.0 emulator/debugger, you could
independently set them in the xxx_prom module for the "run" mode.
In the newer versions, the IPACK bits' evaluation seems to depend on the
first description in ldf file for this physical memory location.
This means, if you have both 48bit wide PM and 32bit wide DM in an external
RAM location, the debugger may get dizzy about the different sections, and
then shows wrong / senseless code and/or data.
To find out if that's the case, try to switch the IPACK bits manually in
debugger state.
If this helps, there might be a chance in reordering the sections in the ldf
file and/or aligning the width during the debug sessions.

It helped me to create a small program, which uses startup code in internal
PM, then called a routine in external PM section, then accessing data in
sections with different widths.

Now I could launch a debugging session, set a breakpoint in the startup code
before external PM is accessed. This worked fine. Then while stepping through
the code I found that the debugger failed exactly when the external PM
location was accessed for the first time.

Switching the IPACK bits manually helped. This demonstrated that not copying
from the flash had been wrong. Only the debugger retrieved/reassembled the
code wrongly.

Maybe we'd better call it "bugger" instead of "debugger" ;-(

Bernhard