cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
flitch@mbda
Contributor
Contributor
4,070 Views
Registered: ‎06-22-2009

XMD stop problem - related to interrupts?

Jump to solution

Hi,

 

I have an interesting /infuriating problem that I would appreciate some help with.

 

I have a working V5 design that runs fine. I can boot from FLASH or load via JTAG no problem and the SW runs perfectly.

 

However, I have now modified the firmware but left the SW unchanged. When this is loaded I cannot get into the processor with xmd anymore. This reports that it is unable to stop the processor.

 

The only significant change I made was to the firmware was to connect a new interrupt from my IP to the interrupt controller. The interrupt is defined as "active high" and I am sure that my IP defaults it low after reset and it is never enabled by the IP.

 

I presume that this is the problem, but why?

 

Reading some of the threads suggest that unexpected interrupts could cause this problem, but I should not be getting any! 

 

What is the minimum that I have to do to get it working. Do I need a full ISR or can I turn it off?

 

Thanks in advance.

 

Best wishes

Peter

 

 

0 Kudos
1 Solution

Accepted Solutions
flitch@mbda
Contributor
Contributor
4,918 Views
Registered: ‎06-22-2009

Thanks Austin,

 

This actually turned out to be a different problem, as the processor was stopping before the SW started running!

 

However, unserviced interrupts can cause the SW to stop, just as you describe. If the interrupts never go active then you are probably OK. Otherwise you need a SW routine to deal with the interrupt. This can simply return, but ideally should disable the interrupt to avoid getting stuck in a loop.

 

My problem was a bad build. Somehow (possibly a problem with the overnight file system maintenance proceedure) one of the IP blocks lost its address assignment and also an external interrupt had vanished. Amazingly the thing still seemed to build OK without any obvious error or warning messages. Perhaps this was because it had been built OK previously? Obviously when loaded into the device it did not work.

 

Good advice therefore may be to always "clean" all generated files before doing a build!

 

Many thanks for your help.

Best wishes

Peter

View solution in original post

0 Kudos
2 Replies
austin
Scholar
Scholar
4,064 Views
Registered: ‎02-27-2008

Peter,


I had a similar problem, when I removed an unused UART.  The resulting interrupts were still connected, and when I tried to start the application, the code would write to the UART (it was used, after all), the processor would "hang" waiting for the transmit ready to clear after the interrupt (as you describe, it was always high).

 

Either create a service routine to mask it, or tie it to ground....

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
flitch@mbda
Contributor
Contributor
4,919 Views
Registered: ‎06-22-2009

Thanks Austin,

 

This actually turned out to be a different problem, as the processor was stopping before the SW started running!

 

However, unserviced interrupts can cause the SW to stop, just as you describe. If the interrupts never go active then you are probably OK. Otherwise you need a SW routine to deal with the interrupt. This can simply return, but ideally should disable the interrupt to avoid getting stuck in a loop.

 

My problem was a bad build. Somehow (possibly a problem with the overnight file system maintenance proceedure) one of the IP blocks lost its address assignment and also an external interrupt had vanished. Amazingly the thing still seemed to build OK without any obvious error or warning messages. Perhaps this was because it had been built OK previously? Obviously when loaded into the device it did not work.

 

Good advice therefore may be to always "clean" all generated files before doing a build!

 

Many thanks for your help.

Best wishes

Peter

View solution in original post

0 Kudos