"Alfmyk" <Alfmyk@hotmail.com> wrote in message
news:eea0f4e.1@webx.sUN8CHnE...
> Hi Clark.
>
> Thanks for your answer. At the moment in the application where ISRs are
present no cache using has been enabled. So I don't think problem should
related to it.
>
> I don't understand very well about interrupt table... I'm using, for the
moment, to register the ISR in dynamic mode with the low level function
XIntc_RegisterHandler(). I tested also the static mode setting handler
function via EDK using software menu and so on... But problem are the
same... Please could you explain better what you mean with "...Vector Table
on 64 KB boundary.." ?
>
> Thank you very much.
>
> Al.

In your linker file there is a section called .vectors. This must be on a
64kbyte boundary. For example, I had a design with only 32kbyte block ram at
0xffff8000 and none of the interrupts would work. I found out that I had to
increase to 64 kByte and start at 0xffff0000 to get it to work.

You may have a similar problem.. Under your linker options you can add -Map
myapp.map to generate a map file that will show the addreses of all the
variables and sections in your code. .vectors should be the first section in
the map so just check where your code starts.

-Clark

Hi Clark.

Thanks for your answer. At the moment in the application where ISRs are present no cache using has been enabled. So I don't think problem should related to it.

I don't understand very well about interrupt table... I'm using, for the moment, to register the ISR in dynamic mode with the low level function XIntc_RegisterHandler(). I tested also the static mode setting handler function via EDK using software menu and so on... But problem are the same... Please could you explain better what you mean with "...Vector Table on 64 KB boundary.." ?

Thank you very much.

Al.

"Alfmyk" <alfmyk@hotmail.com> wrote in message
news:eea0f4e.-1@webx.sUN8CHnE...
> Hi all. I have created a simple application to test ISRs.
>
> This application is very similar to the application example provided by
xilinx with EDK 8.2 for ISR testing: there is a timer and UART ISR.Press f
key leds "blink" faster, while pressing s leds "blink" slower.
>
> This application works fine if loaded directly in BRAM. If I decide to
create the application to be loaded in RAM(so setting .Text start address in
DDR RAM) I founfd troubles. If I create .elf file and download it in RAM<
via EDK no problem, all work well. But if I transform .elf file in .bin file
and I download it in RAM and after jump ion RAM ISRs seem to be vanish
out... Normally using this procedure (transform application in binary, load
it in RAM and jump in RAM) no problem at all I had never seen before...
Please any suggestion ?
>
> Thanks ! It's very important.
>
> Al.

Two things to check: (a) is cache enabled, I've had problems like this in
the past where I had to disable cache to get it to work and (b) is your
interrupt vector table on 64 kbyte boundary, the tool won't complain if it
isn't but it won't work. I would use GDB to see if you at least get to
main(). If so it's probably the IV table.

-Clark

Hi all. I have created a simple application to test ISRs.

This application is very similar to the application example provided by xilinx with EDK 8.2 for ISR testing: there is a timer and UART ISR.Press f key leds "blink" faster, while pressing s leds "blink" slower.

This application works fine if loaded directly in BRAM. If I decide to create the application to be loaded in RAM(so setting .Text start address in DDR RAM) I founfd troubles. If I create .elf file and download it in RAM< via EDK no problem, all work well. But if I transform .elf file in .bin file and I download it in RAM and after jump ion RAM ISRs seem to be vanish out... Normally using this procedure (transform application in binary, load it in RAM and jump in RAM) no problem at all I had never seen before... Please any suggestion ?

Thanks ! It's very important.

Al.