Hi,
I'm starting to develope a program that processes audio, more
especifficaly baby's cry. However, I've been having some
problems.
I get a "time out" message when I'm loading it into the board.
I use DSP 21065L board and VisualDsp++ 1.0.
My ldf file is as follows:
ARCHITECTURE(ADSP-21065L)
SEARCH_DIR( $ADI_DSP\21k\lib )
$LIBRARIES = libc.dlb, libio32.dlb, libcpp.dlb, libcpprt.dlb;
$OBJECTS = $COMMAND_LINE_OBJECTS;
MEMORY
{ seg_rth { TYPE(PM RAM) START(0x00008000) END(0x000080ff) WIDTH(48) } seg_init { TYPE(PM RAM) START(0x00008100) END(0x0000810f) WIDTH(48) } seg_pmco { TYPE(PM RAM) START(0x00020000) END(0x00ffffff) WIDTH(48) } seg_ctdm { TYPE(DM RAM) START(0x0000C000) END(0x0000C0ff) WIDTH(32) } seg_dmda { TYPE(DM RAM) START(0x03000001) END(0x030f00ff) WIDTH(32)
}
seg_bnk3 { TYPE(DM RAM) START(0x030FFF00) END(0x030FFFFF) WIDTH(32)
}
seg_heap { TYPE(DM RAM) START(0x0000D000) END(0x0000D4ff) WIDTH(32)
}
seg_stak { TYPE(DM RAM) START(0x0000D500) END(0x0000Dfff) WIDTH(32) } }
PROCESSOR p0
{ LINK_AGAINST( $COMMAND_LINE_LINK_AGAINST) OUTPUT( $COMMAND_LINE_OUTPUT_FILE ) SECTIONS
{ // .text output section
seg_rth { INPUT_SECTIONS( $OBJECTS(seg_rth) $LIBRARIES(seg_rth)) } >seg_rth seg_init
{ INPUT_SECTIONS( $OBJECTS(seg_init) $LIBRARIES(seg_init)) } >seg_init seg_pmco
{ INPUT_SECTIONS( $OBJECTS(seg_pmco) $LIBRARIES(seg_pmco)) } >seg_pmco seg_pmdm
{ __ctors = .; //points to the start of the section INPUT_SECTIONS( $OBJECTS(seg_ctdm) $LIBRARIES(seg_ctdm)) } > seg_ctdm seg_dmda
{ INPUT_SECTIONS( $OBJECTS(seg_dmda) $LIBRARIES(seg_dmda)) } > seg_dmda seg_bnk3 { INPUT_SECTIONS( $OBJECTS(seg_bnk3) $LIBRARIES(seg_bnk3)) } >seg_bnk3 stackseg { // allocate a stack for the application
ldf_stack_space = .; ldf_stack_length = MEMORY_SIZEOF(seg_stak); } > seg_stak heap
{ // allocate a heap for the application ldf_heap_space = .; ldf_heap_length = MEMORY_SIZEOF(seg_heap); ldf_heap_end = ldf_heap_space + ldf_heap_length - 1; } > seg_heap } } What happens is that when I'm loading the program into the board,
I get the following message:
Target #256: Error #905 Communications TimeOut
Target #256: Error #911 Maximum retry limit broken, Board is in an Unknown State Target #256: Error #14 Reset Board Error reading target memory. Address: 0x942b, Length: 1 I've tried to use External memory banks, but it doesn't seem to
work.
However, I don't have much experience with DSP's.
Thank you,
Natasha Moura Yahoo! Mail - 6MB, anti-spam e antivus gratuito. Crie sua conta agora! |
|
Time Out - DSP 21065L
Started by ●November 27, 2003
Reply by ●November 28, 20032003-11-28
On Thu, 27 Nov 2003, [iso-8859-1] Natasha M. wrote: > What happens is that when I'm loading the program into the board, I get the following message: > > Target #256: Error #905 Communications TimeOut > Target #256: Error #911 Maximum retry limit broken, Board is in an Unknown State > Target #256: Error #14 Reset Board > Error reading target memory. Address: 0x942b, Length: 1 > > I've tried to use External memory banks, but it doesn't seem to work. > However, I don't have much experience with DSP's. The problem is not code, it's connection hardware. How are you connected to the board? Through a serial cable or a JTAG link? If it is thru a serial cable, then the VDSP is unable to find the processor responses. If it's a JTAG cable, then it's more like VDSP can not find the JTAG interface. Look at your connections and make sure all are good, then make sure VDSP knows what connections you have, and what ports they are on. Then check that your reset line is high. There's lots of details. You will get lots of experience learning every one of them :-) Patience, persistence, truth, Dr. mike |
|
Reply by ●November 29, 20032003-11-29
> The problem is not code, it's connection hardware. How are you connected > to the board? Through a serial cable or a JTAG link? If it is thru a > serial cable, then the VDSP is unable to find the processor responses. > If it's a JTAG cable, then it's more like VDSP can not find the JTAG > interface. Look at your connections and make sure all are good, then > make sure VDSP knows what connections you have, and what ports they are > on. Then check that your reset line is high. > > There's lots of details. You will get lots of experience learning every > one of them :-) > > Patience, persistence, truth, > Dr. mike What makes me think that it isn't hardware related is that the program has worked well, without errors, till the day I started using a "deque" (in may first e-mail I forgot to mention that I'm using C++, and I don't know if it makes any diffences). As the error only happens when I use an object of this type (deque), I thougth that it could be related to LDF file or to some limitation in the DSP's implementation of the STL. Even though the program was working before, and still works if I remove the "deque", I rechecked the cables and the conections, and they seemed to be OK. Are there any issues about using a "deque" or any other variable length STL's class? Thank you for your help, Natasha |
|
Reply by ●November 30, 20032003-11-30
--On Saturday, November 29, 2003 12:54:51 AM +0000 nat_moura <> wrote: > Even though the program was working before, and still works if I > remove the "deque", I rechecked the cables and the conections, and > they seemed to be OK. > > Are there any issues about using a "deque" or any other variable > length STL's class? If the ICE stops working, suspect that low memory (I/O space) is getting overwritten in a way that hangs the core. Set a hardware instruction breakpoint for the range 0-7fff and see if the code tries to jump into that region. (Jumping through a NULL pointer will do that.) The hard part is trying to figure out where the code was just before this. You can often figure that out by looking at the software and hardware stacks. (Newer CPU's like the Blackfin have a branch trace buffer for figuring out how you got to some weird place.) I'd guess the most likely cause is that some static class component (possibly even the vtable) isn't getting set up, and perhaps you're not linking the C++ startup code. (It's different from the C startup code.) Turn off "run to main" in the ICE options to make sure you can set the hardware instruction breakpoint before the startup code tries to run. |