|
hi thanx for all of u who helped me to debug the prob. By the Grace of God the prob has been solved, i did it by debuging Frame pointer & Stack Pointer when C routine is called from assembly & going back to Assembly after end of C routine. 1 thing more all Scratch Registers must be saved as soon as it comes in ISR. thanx Bye __________________________________________________ |
Stack Overflow Condition
Started by ●December 25, 2004
Reply by ●December 29, 20042004-12-29
Reply by ●December 29, 20042004-12-29
|
--On Tuesday, December 28, 2004 10:21 AM -0800 Jon Harris <> wrote: > I have one board that has a problem with a 21065L SHARC (many other > "identical" boards work properly). The main symptom I have noticed is > that the bus request line (\BR1) line is always low, even during reset. What silicon rev? Anything before 0.3 shouldn't be used in a multiprocessor system. 0.2 and under were very buggy, particularly for MP use. |
Reply by ●December 30, 20042004-12-30
|
All boards are using rev 0.3 silicon. Thanks for the suggestion though. -Jon --- Kenneth Porter <> wrote: > --On Tuesday, December 28, 2004 10:21 AM -0800 Jon Harris > <> wrote: > > > I have one board that has a problem with a 21065L SHARC (many other > > "identical" boards work properly). The main symptom I have noticed is > > that the bus request line (\BR1) line is always low, even during reset. > > What silicon rev? Anything before 0.3 shouldn't be used in a multiprocessor > system. 0.2 and under were very buggy, particularly for MP use.> __________________________________ |
Reply by ●January 4, 20052005-01-04
|
Hello! although it seems you've solved your problem, the issue did seem familiar to me. I've been working with the 16-bit fixed point ADSP-21992, and had explored interfacing C and assembly, also using interrupts, and learned a few interesting lessons of my own, which might still also be useful to you: - the C run time environment maintains a stack in memory, using I4 and I5, for passing parameters and storing local variables - upon a call to a subroutine or C function, the CPU saves the PC to an internal hardware stack. VDSP provides an option switch -no_hardware_pc_stack, to force the compiler to always pop this PC from the internal stack and copy it to the memory based stack. This is very important, because when calling a C function, you never know what else may be called by that function, and the CPU internal stack is very shallow. Thus, all my assembly routines start with this, and terminate with the opposite process. - a very informative exercise, also suggested in the VDSP documentation, is to set the compiler -save_temps flag, in the project options, and then examine the .S file which results from the compilation, which consists of the assembly source code compiled from the C source. I wrote a few simple dummy programs, where I call dummy routines, with various permutaions of: - taking no or various parameters, - returning void or int, or float, or some struct type - with and without local variables - with and without function calls to examine the resulting code, how parameters are passed and accessed, as well as to build a collection of assembly language subroutine templates with various C interfaces. Also interesting has been a detailed examination of the C start up code, and C interrupt handling code, from setup using the interrupt() library function, to the chain of events from initial interrupt trigger, though the C run time code, and finally to your isr. Working with interrupts in C is admittedly less efficient, because of an inevitable overhead, especially saving ALL the CPU registers (I think I've counted over 50 instructions of saving and setting up registers with C run time default values, before your C isr is actually entered), since one can never know what C functions may be called and therefore what registers will be used. Which is why it is by far wiser and more efficient to write a isr in assembly (if necessary and justified by application and response time requirements, otherwise I still prefer the ease of doing it in C), and really NOT call any C function from a isr in assembly, UNLESS you know exactly what code is called as a result, which then requires a mech deeper understanding of the underlying C runtime mechanism. In summary, mixing C and assembly can be very efficient, but does require quite a thorough understanding of the underlying C run time issues and CPU operation. All the best, Alex K. -----Original Message----- From: talha khan [mailto:] Sent: December 28, 2004 10:07 PM To: ; Saurabh Shah Cc: Subject: Re: [adsp] Stack Overflow Condition hi thanx for all of u who helped me to debug the prob. By the Grace of God the prob has been solved, i did it by debuging Frame pointer & Stack Pointer when C routine is called from assembly & going back to Assembly after end of C routine. 1 thing more all Scratch Registers must be saved as soon as it comes in ISR. thanx Bye __________________________________________________ |
Reply by ●January 12, 20052005-01-12
|
Thanks to all who contibuted to this thread. It turned out to be a bad DSP chip. Replacing it solved the problem. All the evidence pointed to the DSP itself, but I am usually hesitant to pin the blame on an IC. In my experience, by far the most frequent cause of non-working boards are solder problems (shorts or cold joints). Second comes problems with the PCB itself, with ICs coming in third. But in this case, it was indeed the IC. --- Mike Rosing <> wrote: > > On Tue, 28 Dec 2004, Jon Harris wrote: > > > I have one board that has a problem with a 21065L SHARC (many other > "identical" > > boards work properly). The main symptom I have noticed is that the bus > request > > line (\BR1) line is always low, even during reset. The board has 2 21065L > > chips > > connected in a standard multi-processor set-up (i.e. shared busses and > control > > signals). But it appears that DSP ID #1 is driving bus request 1 line low > even > > during reset. This signal is of course connected to both DSPs, so to > isolate > > the problem, I lifted the pin from DSP ID #1. The pin still is driven low, > so > > it seems that the DSP is driving it rather than a short on the board or > problem > > with the other DSP. > > > > My first assumption is that I have a bad DSP chip. But since it is fairly > > difficult and costly to replace the chip, I wanted to see if there was > anything > > else obvious that might cause this behavior. I checked clock, reset, and > chip > > ID and they all looked OK. \HBR and \HBG were both high as expected. The > boot > > mode is set to host boot (\BMS high, BSEL low). Can you think of anything > that > > would cause the bus request line to be driven low? > > The only thing I can think of is power and ground problems. I'd have to > agree with your assesment though, seems like the chip is broken. If it > stays low while reset is low, the output gate is hosed. It's supposed to > be tristate during reset. > > Patience, persistence, truth, > Dr. mike __________________________________ |
