Forums

56303evm irqa and irqd all dead

Started by rtur...@yahoo.de June 26, 2007
hello all,

I have a weird problem. The irqa and irqd switches on my 56303evm have stopped functioning. Everything else is running fine. (it's not about my code, they were both functioning fine before with the same program)
All of this started when I tried to burn my program into flash perom to no success. I have simulated my programs everthing is running okey, but when the interrupt button is pressed, there is simply no response.

During the burning I only compiled flash.asm with the size and the address of the first code word and loaded it into sram and run the device.
Do you think that I should have merged the two codes (flash.asm and my code) together?

I would be happy if you can advice on this topic.
thanks alot
rifat
Dear Rifat,

probably the interrupt vectors for irqa and irqd are corrupted. The probability that the hardware gives up with smoke is almost zero :-).

Please use your debugger and take a look to program addresses p:$10 and p:$16. If you do not find subroutine jump there like this:

P:000010 0BF080 jsr main ;- IRQA
P:000016 0BF080 jsr echo ;- IRQD

you got the solution: The 'echo' subroutine will never be called.

The flash.asm does not include the interrupt vector 'service routines'. Since that you have to be careful to apply the flash 'utility':

1.) load your application but do not run it.
2.) load 'flash.cld'
3.) modify r0 pointing to the start address of the program. This is usually the reset vector at p:$0, so please modify r0 to 0.
4.) modify r1 for the length of the user code in word.
5.) run all this from the debugger. After a while it will stop since there is a 'debug' instruction in the 'flash' code to stop it once it has finished.

The values of r0 and r1 are written to the six first flash addresses that are loaded by the bootlader, so this progam 'knows' the size of the program and where to position it to the internal p:ram.

You do not have to assemble the flash utility with the values for r0 and r1. Simply modify them using your debugger.

Good luck

Christian

>
> hello all,
>
> I have a weird problem. The irqa and irqd switches on my 56303evm have
> stopped functioning. Everything else is running fine. (it's not about my
> code, they were both functioning fine before with the same program)
> All of this started when I tried to burn my program into flash perom to
> no success. I have simulated my programs everthing is running okey, but when
> the interrupt button is pressed, there is simply no response.
>
> During the burning I only compiled flash.asm with the size and the address
> of the first code word and loaded it into sram and run the device.
> Do you think that I should have merged the two codes (flash.asm and my
> code) together?
>
> I would be happy if you can advice on this topic.
> thanks alot
> rifat
well somehow I missed this thread
http://www.dsprelated.com/groups/motoroladsp/show/949.php

answering the flash.asm part of my question, however this time I would like
to ask if somebody would like to share/point out a modified flash.asm that also takes care of the x and y memories.

thanks alot
rifat

> hello all,
>
> I have a weird problem. The irqa and irqd switches on my 56303evm have stopped functioning. Everything else is running fine. (it's not about my code, they were both functioning fine before with the same program)
> All of this started when I tried to burn my program into flash perom to no success. I have simulated my programs everthing is running okey, but when the interrupt button is pressed, there is simply no response.
>
>During the burning I only compiled flash.asm with the size and the address of the first code word and loaded it into sram and run the device.
>Do you think that I should have merged the two codes (flash.asm and my code) together?
>
>I would be happy if you can advice on this topic.
>thanks alot
>rifat
Moin,

Christian Langen wrote:
> Dear Rifat,
>
> probably the interrupt vectors for irqa and irqd are corrupted. The probability that the hardware gives up with smoke is almost zero :-).

According to my experience quite the opposite, I damaged some pins on a DSP56371 by applying too high voltage (5V) to it, other pins were still functioning properly. Think the same could also happen to DSP5303.
Stefan,

You shouldn't be able to damage a 56371 by applying 5v on an I/O pin as
it has 5v tolerant I/O. Of course if you're applying 5v to a
non-tolerant pin then logically you run the risk of damaging the
device. The same goes for any device out there, if you exceed the specs
you're going to damage it...

--
Mark
--- Stefan Stenzel wrote:

> Moin,
>
> Christian Langen wrote:
> > Dear Rifat,
> >
> > probably the interrupt vectors for irqa and irqd are corrupted. The
> probability that the hardware gives up with smoke is almost zero :-).
>
> According to my experience quite the opposite, I damaged some pins on
> a DSP56371 by applying too high voltage (5V) to it, other pins were
> still functioning properly. Think the same could also happen to
> DSP5303.
>
Dear Stefan,

meanwhile we have managed the problem: The IRQA and IRQB were masked in the IPRC (Interrupt Priority Register Core) register.

Regards

Christian

> Moin,
>
> Christian Langen wrote:
> > Dear Rifat,
> >
> > probably the interrupt vectors for irqa and irqd are corrupted. The
> probability that the hardware gives up with smoke is almost zero :-).
>
> According to my experience quite the opposite, I damaged some pins on a
> DSP56371 by applying too high voltage (5V) to it, other pins were still
> functioning properly. Think the same could also happen to DSP5303.