ISR Routine:Copying application in RAM and jumping in it ISR(s) don't start !(?)

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.

Reply to
Alfmyk
Loading thread data ...

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.

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 ?

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

Reply to
Anonymous

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.

Reply to
Alfmyk

present no cache using has been enabled. So I don't think problem should related to it.

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.." ?

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

Reply to
Anonymous

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.