Forums

ADSP 21160 Program Counter Corruption.

Started by Anshuman Sethi October 21, 2003
Hi!,

I am running a program in a loop for some large count on ADSP 21160
operating at 80 MHz. I observed that after running for some counts
the program counter goes to external memory(SRAM mapped into Bank 0)
having all nops. The count after which the program goes into external
memory keeps on varying. The program has no access to external memory
and all the variables are defined in internal memory.

I tried running the same program with small count and faced no
problems. Has anyone faced problem related to corruption of Program
Counter. Can anyone bring brightness to this issue.

Regs,
Anshuman Sethi
Anshuman Sethi wrote:

> Hi!, > > I am running a program in a loop for some large count on ADSP > 21160 operating at 80 MHz. I observed that after running for some > counts the program counter goes to external memory(SRAM mapped > into Bank 0) having all nops. The count after which the program > goes into external memory keeps on varying. The program has no > access to external memory and all the variables are defined in > internal memory. >
Hello, Yes, I know a similar problem (on 21161, VDSP3, EZLITE-USB). It started since the code grew bigger. I didn't consider it as a serious problem, because it seems to happen only in emulator mode. I couldn't detect it if the program were running out of flash with emulator not connected. I have no explanation for the behaviour, but as it happens often, when interrupts occur or when I raise an emulator stop, I guess that it has to do with the readout from DSP memory. Sometimes, emulator shows wrong values of internal states/variables and behaves strange. If I launch a reset command, it doesn't help. But after I power the board off (removing USB cable, too), and the restart it, everything works again. Obviously there ARE strange things going on from time to time. However, in some cases I found errors in my code which were the reason for the system's collapse. Though, this doesn't help you...
> I tried running the same program with small count and faced no > problems. Has anyone faced problem related to corruption of > Program Counter. Can anyone bring brightness to this issue.
If your problem occurs in free running mode (without emulator), you might check these issues: - do interrupts interfere (things like race conditions...) - does an interrupt routine interfere with main program accesses - can stack overflows happen (too many subroutine calls) - wrong return command (rts instead of rti) - do you properly restore registers when interrupts are handled - is your power supply and cabling clean? Often I suspected that the system doesn't work properly, then I found an error in one of the above areas of my hardware/code.
> > Regs, > Anshuman Sethi
HTH Bernhard Holzmayer
Yes, I've seen the same thing.

It seems to have to do with multiple interrupts occurring at or near the
same time as the emulation interrupt.    For some reason, instead of
vectoring to the internal handler, it seems to vector to the external
handler.

By setting the BSO bit, this seems to solve the issue.


PD


"Bernhard Holzmayer" <holzmayer.bernhard@deadspam.com> wrote in message
news:2722368.eux99kF6Jj@holzmayer.ifr.rt...
> Anshuman Sethi wrote: > > > Hi!, > > > > I am running a program in a loop for some large count on ADSP > > 21160 operating at 80 MHz. I observed that after running for some > > counts the program counter goes to external memory(SRAM mapped > > into Bank 0) having all nops. The count after which the program > > goes into external memory keeps on varying. The program has no > > access to external memory and all the variables are defined in > > internal memory. > > > > Hello, > > Yes, I know a similar problem (on 21161, VDSP3, EZLITE-USB). > It started since the code grew bigger. I didn't consider it as a > serious problem, because it seems to happen only in emulator mode. > I couldn't detect it if the program were running out of flash with > emulator not connected. > > I have no explanation for the behaviour, but as it happens often, > when interrupts occur or when I raise an emulator stop, I guess > that it has to do with the readout from DSP memory. > > Sometimes, emulator shows wrong values of internal states/variables > and behaves strange. If I launch a reset command, it doesn't help. > > But after I power the board off (removing USB cable, too), and the > restart it, everything works again. > > Obviously there ARE strange things going on from time to time. > > However, in some cases I found errors in my code which were the > reason for the system's collapse. > > Though, this doesn't help you... > > > I tried running the same program with small count and faced no > > problems. Has anyone faced problem related to corruption of > > Program Counter. Can anyone bring brightness to this issue. > > If your problem occurs in free running mode (without emulator), > you might check these issues: > - do interrupts interfere (things like race conditions...) > - does an interrupt routine interfere with main program accesses > - can stack overflows happen (too many subroutine calls) > - wrong return command (rts instead of rti) > - do you properly restore registers when interrupts are handled > - is your power supply and cabling clean? > > Often I suspected that the system doesn't work properly, then > I found an error in one of the above areas of my hardware/code. > > > > > Regs, > > Anshuman Sethi > > HTH > Bernhard Holzmayer
KG7HF wrote:

> Yes, I've seen the same thing. > > It seems to have to do with multiple interrupts occurring at or > near the > same time as the emulation interrupt. For some reason, instead > of vectoring to the internal handler, it seems to vector to the > external handler. > > By setting the BSO bit, this seems to solve the issue. > > > PD
Hi PD, how did you find this out? Is there a "hidden" source for such sort of information? When do you set the BSO bit? I guess you do so after loading and before running the program. Is this correct? Bernhard -- before sending to the above email-address: replace deadspam.com by foerstergroup.de
What I found (using hardware breakpoints) was that the code was vectoring to
the external interrupt vector address.

What I did was to set the BSO bit in my code at the very beginning of the
program.  If you are using 'C', you can set it in the RTL startup code.

PD


"Bernhard Holzmayer" <holzmayer.bernhard@deadspam.com> wrote in message
news:4599449.TjrtHfKrYD@holzmayer.ifr.rt...
> KG7HF wrote: > > > Yes, I've seen the same thing. > > > > It seems to have to do with multiple interrupts occurring at or > > near the > > same time as the emulation interrupt. For some reason, instead > > of vectoring to the internal handler, it seems to vector to the > > external handler. > > > > By setting the BSO bit, this seems to solve the issue. > > > > > > PD > > Hi PD, > how did you find this out? > Is there a "hidden" source for such sort of information? > > When do you set the BSO bit? > I guess you do so after loading and before running the program. > Is this correct? > > Bernhard > > -- > before sending to the above email-address: > replace deadspam.com by foerstergroup.de