UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Participant thngttr
Participant
1,914 Views
Registered: ‎03-13-2017

interrupt routing

Jump to solution

Hi!
I had linux on cpu0 and baremetal on cpu1 and they were successfully communicating via remoteproc.
Then i added uart0 interrupt handling.
After few [receive interrupt -> send bytes] iterations baremetal application either goes to Xil_UndefinedExceptionHandler or stops receiving interrupts at all.
Without linux, uart0 app works fine.
Here is device tree (system-user.dtsi):

    reserved-memory {
        #address-cells = <1>;
        #size-cells = <1>;
        ranges;
        rproc_0_reserved: rproc@100000 {
            no-map;
            reg =  <0x100000 0x16F00000>;
        };
		
    };
    amba {
        elf_ddr_0: ddr@0 {
            compatible = "mmio-sram";
            reg = <0x100000 0x15F00000>;
        };
		
    };
    remoteproc0: remoteproc@0 {
        compatible = "xlnx,zynq_remoteproc";
        firmware = "firmware";
        vring0 = <15>;
        vring1 = <14>;
        srams = <&elf_ddr_0>;
		interrupt-parent = <&intc>;
		interrupts = <0 27 4>; //uart0 interrupt routing!
    };
    chosen {
		bootargs = "clk_ignore_unused";
	};



&uart0 {
	compatible="invalid";
};

 

kernel base address - 0x18000000

netboot offset - 0x19000000

 

rsc_table.c:

RING_TX - 0x16000000
RING_RX - 0x16004000

{RSC_RPROC_MEM, 0x16000000, 0x16000000, 0x100000, 0}


lscript.ld:
ddr base - 0x00100000

size - 0x15F00000

Is there something else that needs to be done to route interrupt to cpu1? (XScuGic_InterruptMaptoCpu is used)

Can it be memory related error? Any hint would be really welcome.

0 Kudos
1 Solution

Accepted Solutions
Participant thngttr
Participant
2,541 Views
Registered: ‎03-13-2017

Re: interrupt routing

Jump to solution

Well, problem was not related to linux or OpenAMP at all, but to mere lack of space in stack, or rather, irq_stack sector. Which was only 1024 bytes in size, and therefore use of heavy sprintf caused stack corruption.


lscript fix:

_IRQ_STACK_SIZE = DEFINED(_IRQ_STACK_SIZE) ? _IRQ_STACK_SIZE : 1024 0x2000

 

0 Kudos
6 Replies
Moderator
Moderator
1,885 Views
Registered: ‎05-10-2017

Re: interrupt routing

Jump to solution

Which version of the tools are you on? Is this on Zynq or ZynqUltrascale+?

 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Highlighted
Participant thngttr
Participant
1,860 Views
Registered: ‎03-13-2017

Re: interrupt routing

Jump to solution

Zynq 7000 and Vivado/Petalinux 2017.4

0 Kudos
Participant thngttr
Participant
1,840 Views
Registered: ‎03-13-2017

Re: interrupt routing

Jump to solution

Don't know if it means anything (because looking at the code (1 and 2) - it shouldn't) every time at first interrupt linux gives the following output:
C_Users_engineer18.VREMENA_AppData_Local_Packages_Microsoft.SkypeApp_kzf8qxf38zg5c_LocalState_400ced25-4444-4520-8084-e675f70e8052.PNG
Usually it's IRQ 49, which corresponds with remoteproc-uart0 interrupt (cat /proc/interrupts):
q.png

But sometimes it's 26 - which is uart1. And 48 doesn't correspond to anything.

0 Kudos
Participant thngttr
Participant
1,764 Views
Registered: ‎03-13-2017

Re: interrupt routing

Jump to solution

So, I've debugged the program by removing peaces of code and looking what corrupts the flow of the program. Trouble function turned out to be sprintf - it was corrupting the stack:
a.jpg

b.jpg

main() calls freemove() and then interrupt occurs and handler calls sprintf(), during which stack loses pointer to main(), which causes program to fail.
sprintf() is replacable, of course, but reason why this happens is still unclear. Memory in the stack should be enough to hold this amount of information.

0 Kudos
Participant thngttr
Participant
1,752 Views
Registered: ‎03-13-2017

Re: interrupt routing

Jump to solution

Removed linux from the system - now it's simple baremetal app on cpu0 with interrupts on buttons. Interrupt handler calls sprintf. Same picture as before (stack loses main() and cannot return to it).

P.S. Or it was. After several power resets sprintf stopped breaking stack. This needs more testing.

0 Kudos
Participant thngttr
Participant
2,542 Views
Registered: ‎03-13-2017

Re: interrupt routing

Jump to solution

Well, problem was not related to linux or OpenAMP at all, but to mere lack of space in stack, or rather, irq_stack sector. Which was only 1024 bytes in size, and therefore use of heavy sprintf caused stack corruption.


lscript fix:

_IRQ_STACK_SIZE = DEFINED(_IRQ_STACK_SIZE) ? _IRQ_STACK_SIZE : 1024 0x2000

 

0 Kudos