effective wave to debug bsp_spurious_handler trap?
Sebastian Huber
sebastian.huber at embedded-brains.de
Thu Nov 17 06:06:15 UTC 2016
Hello Chan Kim,
which BSP and RTEMS do you use? I guess its some LEON BSP. Here we have:
static rtems_isr bsp_spurious_handler(
rtems_vector_number trap,
CPU_Interrupt_frame *isf
)
First you have to figure out which trap you actually get. In the
interrupt frame you find the offending context, e.g. register set and
program counter.
On 16/11/16 17:04, Chan Kim wrote:
>
>
>
>
>
>
>
> Hello, rtems users,
> I'm seeing bsp_spurious_handler trap in an rtems appplication running on a sparc processor designed in our team.
> It's kind of a test program. And it receives data from camera and performs convolution with weights read from SD card. Currently the trap occurs while convolution (many loops accessing memory) and I found when I put printf somewhere in the loop, I don't see the trap (but very slow). The number is printed sometimes 297 and sometimes 263. I tried printing the program counter and it is in printf and sometimes shows somewhere in a structure called 'rtems_filesystem_default_pathconf'. I'm not sure if this program counter is really where the trap happed.
> It should almost impossible to run hardware simulation for this complex program of course. Isn't there any well known trick that I can use debug where the trap is coming from? Of course I'll spend some time reading related documents.
> Thanks.
> Chan Kim / ETRI
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.huber at embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
More information about the users
mailing list