Hello,
I am experiencing what seems to be a spurious SWI call.
The effect is that the application hangs on the SWI Handler
__asm void SWI_Handler (void):
SWI_Dead
BHS SWI_Dead ; Loop if none Existing SWI
What can I do to identify the origin of this spurious call?
The ARM processor is the LPC2387. I am using Keil RTOS and compiler version:
IDE-Version:
Vision3 V3.80
Copyright (c) Keil Elektronik GmbH / Keil Software, Inc. 1995 - 2009
Tool Version Numbers:
Toolchain: RealView MDK-ARM Version: 3.50
Middleware: RL-ARM Real-Time Library Version V3.50
Toolchain Path: BIN40\
C Compiler: Armcc.Exe V4.0.0.524
Assembler: Armasm.Exe V4.0.0.524
Linker/Locator: ArmLink.Exe V4.0.0.524
Librarian: ArmAr.Exe V4.0.0.524
Hex Converter: FromElf.Exe V4.0.0.524
CPU DLL: SARM.DLL V3.50
Dialog DLL: DARMP.DLL V1.44
Target DLL: BIN\UL2ARM.DLL V1.47
Dialog DLL: TARMP.DLL V1.44
Regards,
Andre
Spurious SWI call (SWI_Dead lock)
Started by ●September 24, 2009
Reply by ●September 24, 20092009-09-24
Set a breakpoint on SWI handler, and check the return address for the SWI
call.
I think that some libraries from keil may be calling SWI in some situations
(not 100% sure).
Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 91 120 1798
+34 636 52 25 69
skype: ajoajoajo
2009/9/24 andre_moutinho
> Hello,
>
> I am experiencing what seems to be a spurious SWI call.
> The effect is that the application hangs on the SWI Handler
> __asm void SWI_Handler (void):
>
> SWI_Dead
> BHS SWI_Dead ; Loop if none Existing SWI
>
> What can I do to identify the origin of this spurious call?
>
> The ARM processor is the LPC2387. I am using Keil RTOS and compiler
> version:
>
> IDE-Version:
> Vision3 V3.80
> Copyright (c) Keil Elektronik GmbH / Keil Software, Inc. 1995 - 2009
>
> Tool Version Numbers:
> Toolchain: RealView MDK-ARM Version: 3.50
> Middleware: RL-ARM Real-Time Library Version V3.50
> Toolchain Path: BIN40\
> C Compiler: Armcc.Exe V4.0.0.524
> Assembler: Armasm.Exe V4.0.0.524
> Linker/Locator: ArmLink.Exe V4.0.0.524
> Librarian: ArmAr.Exe V4.0.0.524
> Hex Converter: FromElf.Exe V4.0.0.524
> CPU DLL: SARM.DLL V3.50
> Dialog DLL: DARMP.DLL V1.44
> Target DLL: BIN\UL2ARM.DLL V1.47
> Dialog DLL: TARMP.DLL V1.44
>
> Regards,
> Andre
>
>
>
call.
I think that some libraries from keil may be calling SWI in some situations
(not 100% sure).
Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 91 120 1798
+34 636 52 25 69
skype: ajoajoajo
2009/9/24 andre_moutinho
> Hello,
>
> I am experiencing what seems to be a spurious SWI call.
> The effect is that the application hangs on the SWI Handler
> __asm void SWI_Handler (void):
>
> SWI_Dead
> BHS SWI_Dead ; Loop if none Existing SWI
>
> What can I do to identify the origin of this spurious call?
>
> The ARM processor is the LPC2387. I am using Keil RTOS and compiler
> version:
>
> IDE-Version:
> Vision3 V3.80
> Copyright (c) Keil Elektronik GmbH / Keil Software, Inc. 1995 - 2009
>
> Tool Version Numbers:
> Toolchain: RealView MDK-ARM Version: 3.50
> Middleware: RL-ARM Real-Time Library Version V3.50
> Toolchain Path: BIN40\
> C Compiler: Armcc.Exe V4.0.0.524
> Assembler: Armasm.Exe V4.0.0.524
> Linker/Locator: ArmLink.Exe V4.0.0.524
> Librarian: ArmAr.Exe V4.0.0.524
> Hex Converter: FromElf.Exe V4.0.0.524
> CPU DLL: SARM.DLL V3.50
> Dialog DLL: DARMP.DLL V1.44
> Target DLL: BIN\UL2ARM.DLL V1.47
> Dialog DLL: TARMP.DLL V1.44
>
> Regards,
> Andre
>
>
>
Reply by ●September 24, 20092009-09-24
Thanks for you reply Miguel.
The situation is as follows:
The software runs communicating through a CAN interface.
After approximately 5 minutes it hangs up in a SWI_Dead loop.
Analysing the call stack, the SWI call occurred from inside a function called from an interrupt routine, in the sequence below (CAN_Handler is the interrupt routine)
CAN_Handler() -> CAN_RX2_ISR() -> CAN_hw_rd() -> SWI??
The problem is there is no explicit call to SWI from inside CAN_hw_rd().
The return address is described bellow:
// detail from CAN_hw_rd() :
0x00032100 E2402001 SUB R2,R0,#0x00000001
378: regCAN *ptrcan = (regCAN *) CAN_BASE[ctrl0];
379:
0x00032104 E59F4780 LDR R4,[PC,#0x0780]
0x00032108 E794E102 LDR R14,[R4,R2,LSL #2]
381: CANData = ptrcan->CANRFS;
0x0003210C E59E3020 LDR R3,[R14,#0x0020]
382: msg->format = (CANData & 0x80000000) == 0x80000000;
0x00032110 E1A04FA3 MOV R4,R3,LSR #31
0x00032114 E5C1400E STRB R4,[R1,#0x000E]
383: msg->type = (CANData & 0x40000000) == 0x40000000;
0x00032118 E2034101 AND R4,R3,#0x40000000 << spurious SWI call
0x0003211C E1A04F24 MOV R4,R4,LSR #30
0x00032120 E5C1400F STRB R4,[R1,#0x000F]
384: msg->len = ((U8)(CANData >> 16)) & 0x0F;
385:
0x00032124 E3A0400F MOV R4,#0x0000000F
0x00032128 E0044823 AND R4,R4,R3,LSR #16
0x0003212C E5C1400C STRB R4,[R1,#0x000C]
387: msg->id = ptrcan->CANRID;
388:
0x00032130 E59E4024 LDR R4,[R14,#0x0024]
0x00032134 E5814000 STR R4,[R1]
390: if (msg->type == DATA_FRAME)
Thanks a lot,
Andre
--- In l..., Miguel Angel wrote:
>
> Set a breakpoint on SWI handler, and check the return address for the SWI
> call.
>
> I think that some libraries from keil may be calling SWI in some situations
> (not 100% sure).
>
> Miguel Angel Ajo Pelayo
> http://www.nbee.es
> +34 91 120 1798
> +34 636 52 25 69
> skype: ajoajoajo
>
>
> 2009/9/24 andre_moutinho
>
> >
> >
> > Hello,
> >
> > I am experiencing what seems to be a spurious SWI call.
> > The effect is that the application hangs on the SWI Handler
> > __asm void SWI_Handler (void):
> >
> > SWI_Dead
> > BHS SWI_Dead ; Loop if none Existing SWI
> >
> > What can I do to identify the origin of this spurious call?
> >
> > The ARM processor is the LPC2387. I am using Keil RTOS and compiler
> > version:
> >
> > IDE-Version:
> > Vision3 V3.80
> > Copyright (c) Keil Elektronik GmbH / Keil Software, Inc. 1995 - 2009
> >
> > Tool Version Numbers:
> > Toolchain: RealView MDK-ARM Version: 3.50
> > Middleware: RL-ARM Real-Time Library Version V3.50
> > Toolchain Path: BIN40\
> > C Compiler: Armcc.Exe V4.0.0.524
> > Assembler: Armasm.Exe V4.0.0.524
> > Linker/Locator: ArmLink.Exe V4.0.0.524
> > Librarian: ArmAr.Exe V4.0.0.524
> > Hex Converter: FromElf.Exe V4.0.0.524
> > CPU DLL: SARM.DLL V3.50
> > Dialog DLL: DARMP.DLL V1.44
> > Target DLL: BIN\UL2ARM.DLL V1.47
> > Dialog DLL: TARMP.DLL V1.44
> >
> > Regards,
> > Andre
> >
> >
> >
>
>
>
>
The situation is as follows:
The software runs communicating through a CAN interface.
After approximately 5 minutes it hangs up in a SWI_Dead loop.
Analysing the call stack, the SWI call occurred from inside a function called from an interrupt routine, in the sequence below (CAN_Handler is the interrupt routine)
CAN_Handler() -> CAN_RX2_ISR() -> CAN_hw_rd() -> SWI??
The problem is there is no explicit call to SWI from inside CAN_hw_rd().
The return address is described bellow:
// detail from CAN_hw_rd() :
0x00032100 E2402001 SUB R2,R0,#0x00000001
378: regCAN *ptrcan = (regCAN *) CAN_BASE[ctrl0];
379:
0x00032104 E59F4780 LDR R4,[PC,#0x0780]
0x00032108 E794E102 LDR R14,[R4,R2,LSL #2]
381: CANData = ptrcan->CANRFS;
0x0003210C E59E3020 LDR R3,[R14,#0x0020]
382: msg->format = (CANData & 0x80000000) == 0x80000000;
0x00032110 E1A04FA3 MOV R4,R3,LSR #31
0x00032114 E5C1400E STRB R4,[R1,#0x000E]
383: msg->type = (CANData & 0x40000000) == 0x40000000;
0x00032118 E2034101 AND R4,R3,#0x40000000 << spurious SWI call
0x0003211C E1A04F24 MOV R4,R4,LSR #30
0x00032120 E5C1400F STRB R4,[R1,#0x000F]
384: msg->len = ((U8)(CANData >> 16)) & 0x0F;
385:
0x00032124 E3A0400F MOV R4,#0x0000000F
0x00032128 E0044823 AND R4,R4,R3,LSR #16
0x0003212C E5C1400C STRB R4,[R1,#0x000C]
387: msg->id = ptrcan->CANRID;
388:
0x00032130 E59E4024 LDR R4,[R14,#0x0024]
0x00032134 E5814000 STR R4,[R1]
390: if (msg->type == DATA_FRAME)
Thanks a lot,
Andre
--- In l..., Miguel Angel wrote:
>
> Set a breakpoint on SWI handler, and check the return address for the SWI
> call.
>
> I think that some libraries from keil may be calling SWI in some situations
> (not 100% sure).
>
> Miguel Angel Ajo Pelayo
> http://www.nbee.es
> +34 91 120 1798
> +34 636 52 25 69
> skype: ajoajoajo
>
>
> 2009/9/24 andre_moutinho
>
> >
> >
> > Hello,
> >
> > I am experiencing what seems to be a spurious SWI call.
> > The effect is that the application hangs on the SWI Handler
> > __asm void SWI_Handler (void):
> >
> > SWI_Dead
> > BHS SWI_Dead ; Loop if none Existing SWI
> >
> > What can I do to identify the origin of this spurious call?
> >
> > The ARM processor is the LPC2387. I am using Keil RTOS and compiler
> > version:
> >
> > IDE-Version:
> > Vision3 V3.80
> > Copyright (c) Keil Elektronik GmbH / Keil Software, Inc. 1995 - 2009
> >
> > Tool Version Numbers:
> > Toolchain: RealView MDK-ARM Version: 3.50
> > Middleware: RL-ARM Real-Time Library Version V3.50
> > Toolchain Path: BIN40\
> > C Compiler: Armcc.Exe V4.0.0.524
> > Assembler: Armasm.Exe V4.0.0.524
> > Linker/Locator: ArmLink.Exe V4.0.0.524
> > Librarian: ArmAr.Exe V4.0.0.524
> > Hex Converter: FromElf.Exe V4.0.0.524
> > CPU DLL: SARM.DLL V3.50
> > Dialog DLL: DARMP.DLL V1.44
> > Target DLL: BIN\UL2ARM.DLL V1.47
> > Dialog DLL: TARMP.DLL V1.44
> >
> > Regards,
> > Andre
> >
> >
> >
>
>
>
>
Reply by ●September 24, 20092009-09-24
I agree... it's really strange.
Which micro are you using?
Is your startup.s setup correctly? , may be the Data Abort handler could be
falling to SWI handler
after all ... Could you check processor level when stopping with JTAG at
that SWI "default handler" ?
(just to check that we aren't at DABT ..)
(STRB R4,[R1,#0x000E]) is just the instruction before your "return point".
In the other hand some micros have erratas describing LDMIA/STMIA errors,
but your code
isn't using such instructions at that point...
Those are the worst errors... the ones that are only reproduced after some
run-time.....
Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 91 120 1798
+34 636 52 25 69
skype: ajoajoajo
2009/9/24 andre_moutinho
> Thanks for you reply Miguel.
>
> The situation is as follows:
> The software runs communicating through a CAN interface.
> After approximately 5 minutes it hangs up in a SWI_Dead loop.
> Analysing the call stack, the SWI call occurred from inside a function
> called from an interrupt routine, in the sequence below (CAN_Handler is the
> interrupt routine)
> CAN_Handler() -> CAN_RX2_ISR() -> CAN_hw_rd() -> SWI??
>
> The problem is there is no explicit call to SWI from inside CAN_hw_rd().
>
> The return address is described bellow:
>
> // detail from CAN_hw_rd() :
>
> 0x00032100 E2402001 SUB R2,R0,#0x00000001
> 378: regCAN *ptrcan = (regCAN *) CAN_BASE[ctrl0];
> 379:
> 0x00032104 E59F4780 LDR R4,[PC,#0x0780]
> 0x00032108 E794E102 LDR R14,[R4,R2,LSL #2]
> 381: CANData = ptrcan->CANRFS;
> 0x0003210C E59E3020 LDR R3,[R14,#0x0020]
> 382: msg->format = (CANData & 0x80000000) == 0x80000000;
> 0x00032110 E1A04FA3 MOV R4,R3,LSR #31
> 0x00032114 E5C1400E STRB R4,[R1,#0x000E]
> 383: msg->type = (CANData & 0x40000000) == 0x40000000;
> 0x00032118 E2034101 AND R4,R3,#0x40000000 << spurious SWI call
> 0x0003211C E1A04F24 MOV R4,R4,LSR #30
> 0x00032120 E5C1400F STRB R4,[R1,#0x000F]
> 384: msg->len = ((U8)(CANData >> 16)) & 0x0F;
> 385:
> 0x00032124 E3A0400F MOV R4,#0x0000000F
> 0x00032128 E0044823 AND R4,R4,R3,LSR #16
> 0x0003212C E5C1400C STRB R4,[R1,#0x000C]
> 387: msg->id = ptrcan->CANRID;
> 388:
> 0x00032130 E59E4024 LDR R4,[R14,#0x0024]
> 0x00032134 E5814000 STR R4,[R1]
> 390: if (msg->type == DATA_FRAME)
>
> Thanks a lot,
> Andre
> --- In l... , Miguel Angel
> wrote:
> >
> > Set a breakpoint on SWI handler, and check the return address for the SWI
> > call.
> >
> > I think that some libraries from keil may be calling SWI in some
> situations
> > (not 100% sure).
> >
> > Miguel Angel Ajo Pelayo
> > http://www.nbee.es
> > +34 91 120 1798
> > +34 636 52 25 69
> > skype: ajoajoajo
> >
> >
> > 2009/9/24 andre_moutinho >
> > >
> > >
> > > Hello,
> > >
> > > I am experiencing what seems to be a spurious SWI call.
> > > The effect is that the application hangs on the SWI Handler
> > > __asm void SWI_Handler (void):
> > >
> > > SWI_Dead
> > > BHS SWI_Dead ; Loop if none Existing SWI
> > >
> > > What can I do to identify the origin of this spurious call?
> > >
> > > The ARM processor is the LPC2387. I am using Keil RTOS and compiler
> > > version:
> > >
> > > IDE-Version:
> > > Vision3 V3.80
> > > Copyright (c) Keil Elektronik GmbH / Keil Software, Inc. 1995 - 2009
> > >
> > > Tool Version Numbers:
> > > Toolchain: RealView MDK-ARM Version: 3.50
> > > Middleware: RL-ARM Real-Time Library Version V3.50
> > > Toolchain Path: BIN40\
> > > C Compiler: Armcc.Exe V4.0.0.524
> > > Assembler: Armasm.Exe V4.0.0.524
> > > Linker/Locator: ArmLink.Exe V4.0.0.524
> > > Librarian: ArmAr.Exe V4.0.0.524
> > > Hex Converter: FromElf.Exe V4.0.0.524
> > > CPU DLL: SARM.DLL V3.50
> > > Dialog DLL: DARMP.DLL V1.44
> > > Target DLL: BIN\UL2ARM.DLL V1.47
> > > Dialog DLL: TARMP.DLL V1.44
> > >
> > > Regards,
> > > Andre
> > >
> > >
> > >
> >
> >
> >
> >
>
Which micro are you using?
Is your startup.s setup correctly? , may be the Data Abort handler could be
falling to SWI handler
after all ... Could you check processor level when stopping with JTAG at
that SWI "default handler" ?
(just to check that we aren't at DABT ..)
(STRB R4,[R1,#0x000E]) is just the instruction before your "return point".
In the other hand some micros have erratas describing LDMIA/STMIA errors,
but your code
isn't using such instructions at that point...
Those are the worst errors... the ones that are only reproduced after some
run-time.....
Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 91 120 1798
+34 636 52 25 69
skype: ajoajoajo
2009/9/24 andre_moutinho
> Thanks for you reply Miguel.
>
> The situation is as follows:
> The software runs communicating through a CAN interface.
> After approximately 5 minutes it hangs up in a SWI_Dead loop.
> Analysing the call stack, the SWI call occurred from inside a function
> called from an interrupt routine, in the sequence below (CAN_Handler is the
> interrupt routine)
> CAN_Handler() -> CAN_RX2_ISR() -> CAN_hw_rd() -> SWI??
>
> The problem is there is no explicit call to SWI from inside CAN_hw_rd().
>
> The return address is described bellow:
>
> // detail from CAN_hw_rd() :
>
> 0x00032100 E2402001 SUB R2,R0,#0x00000001
> 378: regCAN *ptrcan = (regCAN *) CAN_BASE[ctrl0];
> 379:
> 0x00032104 E59F4780 LDR R4,[PC,#0x0780]
> 0x00032108 E794E102 LDR R14,[R4,R2,LSL #2]
> 381: CANData = ptrcan->CANRFS;
> 0x0003210C E59E3020 LDR R3,[R14,#0x0020]
> 382: msg->format = (CANData & 0x80000000) == 0x80000000;
> 0x00032110 E1A04FA3 MOV R4,R3,LSR #31
> 0x00032114 E5C1400E STRB R4,[R1,#0x000E]
> 383: msg->type = (CANData & 0x40000000) == 0x40000000;
> 0x00032118 E2034101 AND R4,R3,#0x40000000 << spurious SWI call
> 0x0003211C E1A04F24 MOV R4,R4,LSR #30
> 0x00032120 E5C1400F STRB R4,[R1,#0x000F]
> 384: msg->len = ((U8)(CANData >> 16)) & 0x0F;
> 385:
> 0x00032124 E3A0400F MOV R4,#0x0000000F
> 0x00032128 E0044823 AND R4,R4,R3,LSR #16
> 0x0003212C E5C1400C STRB R4,[R1,#0x000C]
> 387: msg->id = ptrcan->CANRID;
> 388:
> 0x00032130 E59E4024 LDR R4,[R14,#0x0024]
> 0x00032134 E5814000 STR R4,[R1]
> 390: if (msg->type == DATA_FRAME)
>
> Thanks a lot,
> Andre
> --- In l... , Miguel Angel
> wrote:
> >
> > Set a breakpoint on SWI handler, and check the return address for the SWI
> > call.
> >
> > I think that some libraries from keil may be calling SWI in some
> situations
> > (not 100% sure).
> >
> > Miguel Angel Ajo Pelayo
> > http://www.nbee.es
> > +34 91 120 1798
> > +34 636 52 25 69
> > skype: ajoajoajo
> >
> >
> > 2009/9/24 andre_moutinho >
> > >
> > >
> > > Hello,
> > >
> > > I am experiencing what seems to be a spurious SWI call.
> > > The effect is that the application hangs on the SWI Handler
> > > __asm void SWI_Handler (void):
> > >
> > > SWI_Dead
> > > BHS SWI_Dead ; Loop if none Existing SWI
> > >
> > > What can I do to identify the origin of this spurious call?
> > >
> > > The ARM processor is the LPC2387. I am using Keil RTOS and compiler
> > > version:
> > >
> > > IDE-Version:
> > > Vision3 V3.80
> > > Copyright (c) Keil Elektronik GmbH / Keil Software, Inc. 1995 - 2009
> > >
> > > Tool Version Numbers:
> > > Toolchain: RealView MDK-ARM Version: 3.50
> > > Middleware: RL-ARM Real-Time Library Version V3.50
> > > Toolchain Path: BIN40\
> > > C Compiler: Armcc.Exe V4.0.0.524
> > > Assembler: Armasm.Exe V4.0.0.524
> > > Linker/Locator: ArmLink.Exe V4.0.0.524
> > > Librarian: ArmAr.Exe V4.0.0.524
> > > Hex Converter: FromElf.Exe V4.0.0.524
> > > CPU DLL: SARM.DLL V3.50
> > > Dialog DLL: DARMP.DLL V1.44
> > > Target DLL: BIN\UL2ARM.DLL V1.47
> > > Dialog DLL: TARMP.DLL V1.44
> > >
> > > Regards,
> > > Andre
> > >
> > >
> > >
> >
> >
> >
> >
>
