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