06-20-2019 01:48 PM
I have a project works OK in 2018.2 with LwIP202. Upgraded to 2019.1 with LwIP211, code compiles fine, and runs a bit but always fails at the exact number of user interaction through UDP communications.
Debugger goes into:
synchronoushandler: bl SynchronousInterrupt
And stuck in while(1) loop. Don't have experience in debugging ARM synchronous abort issue.
Did some google, seems IFSR (Instruction Fault Status Register) is able to indicate type of interrupt source, but don't know where to find this register. SDK Registers pane gives: r1-r30 sp, pc, cpsr, vfp, sys, dbg, acpu_gic.
Please shed some light on how to approach this problem.
06-20-2019 02:37 PM
I don't think I can provide a definitive answer, but I want to share with you the time I had a similar issue and how I resolved it and maybe it can give you a starting point to troubleshoot your problem.
First thing first, as you may now know after your researches, a synchronous abort happens when an instruction you just did aborted (action, immediate reaction).
When I had this issue, I was using petalinux, so the kernel abort handler give me much more information about the context. I assume you are running in bare metal so in order to retreive the exact instruction address that caused the abort you would have to compute the said address yourself based on the IFSR (if I recall correctly). Based on the information contained in the registers of the CPU, linux was able to point out that is was a 'synchronous external abort', which means that something outside of the CPU caused the abort. In my case, it was the AXI bus going to the FPGA. With the instruction address that linux provided, I was able to deconstruct the kernel module I created for the custom IP I created.
<somewhere_in_petalinux_dir>/objdump -dS --adjust-vma=<virtual_address_given_by_handler> module.ko > output.S
I discovered that the instruction that caused the abort was a register read of my custom IP. I fact, in my IP there was a AXI4 to AXI Stream fifo, and it was the packet length I was trying to read.
The documentation of the IP did not mentioned that if the fifo was empty, reading the message length register would cause a abort (not just reading as 0 as I thought).
Anyway, long story short... Try so isolate the faulty instruction. Try to check if it is some IP in the PL that caused it, and hopefully it will be something similar to my case. Read the documentation of your IP very carefully for any particularity regarding registers access order.