AW: ADSP-21065L hangs

Started by Bernhard Holzmayer September 27, 2004
> -----Ursprgliche Nachricht-----
> Von: sanglierv [SMTP:]
> Gesendet am: Freitag, 24. September 2004 11:33
> An:
> Betreff: [adsp] ADSP-21065L hangs
>
> Hi,
>
> I am trying to get a talkthrough program working on the DSP-21065L
> EZ-Kit Lite, using VisualDSP++ 3.5.3.0. My code is from the BP
> project, located under C:/VisualDSP++3.
> 5for32-Bit/21k/EZ-Kits/21065L/Demos/.
>
> I had to modify the following two lines in the LDF-file slightly,
> from
>
> seg_rth { TYPE(PM RAM) START(0x00008000) END(0x0000808e) WIDTH(48) }
> seg_init { TYPE(PM RAM) START(0x0000c000) END(0x0000c007) WIDTH(48) }
> to
> seg_rth { TYPE(PM RAM) START(0x00008000) END(0x000080FF) WIDTH(48) }
> seg_init { TYPE(PM RAM) START(0x0000c000) END(0x0000c007) WIDTH(48) }
> in order to get the program to compile. After that I was able to
> compile, download and start the program, but when I try to stop it I
> get the following error message:
>
> Target #256: Error #905 Communications TimeOut
>
> Anybody else that have seen this problem with the DSP-21065L EZ-Kit
> Lite?
>

I don't have the current example code around, since I've actually installed only
21161 stuff.
Nevertheless, I guess that the LDF layout is comparable.
And, at least, I can assure you that the CTalkThru program in an earlier 21065
version
worked without problems here, and the current 21161-version does, too. seg_rth and seg_init
are there to serve special purposes.
You should only modify them, if you're skilled enough to understand what you do.
If you're interested in the historical backgrounds, read the release notes of
the past year.

Normally, user code which you write, should go into seg_pmco.
I'm rather sure that this segment exists in your LDF file, too.

On the other hand: The linker should have warned you, if it
wouldn't have been able to link your program without layout conflicts.

Since you don't tell about linker issues, I guess that it didn't throw a warning
or an error.
If so, your program should run.
This means, that it probably does, what you told it to do (which is not,
automatically,
what you intended it to do...)

I'm used to see such errors, if either I have trouble with the heap/stack
management,
or an uncaught interrupt occurs.
The latest should not have occurred, if you didn't install or at least enable
another interrupt,
which doesn't happen unnoticed (and therefore obviously is not the case here).

Mixing C and asm routines is a good chance to corrupt the heap and/or stack.
Though your main program fails and runs wild, this may go almost unnoticed,
since your system does most of the data related issues during interrupt service
routines,
which might still work.
But there's good chance in such a scenario, that you'll receive this sort of
comm. errors.

Single stepping all paths of your code might reveal the problem.
Your VisualDSP++ documentation contains information about these issues.

If you did try to run the example program without modifying it, it might help if
you would
tell, which error messages and warnings occurred,
and why you did modify the LDF file.

Good luck
Bernhard