Target server error divide by zero ?

Follow

Gordon Scott

• June 11, 2014 10:17

Hi,

I have an application on an STM32F205 that occasionally gives the above error in a pop-up on Crossworks. The "divide by zero" also appears in the status bar.

When it's done that, the application has usually halted in ctl_private_reschedule(), though that may just reflect that it spends much of its time there.

This looks to me like a problem with the debugger, but I certainly can't be sure of that.

I wondered whether anyone could shine any light on what's happening.

CrossWorks for ARM
Release 2.3.2.2013051717.18363
Linux x86

I doubt it's relevant, but I'm chasing a problem where the USB on my target works fine with  Linux host, but both USB data lines go high at the end of enumeration with Windows (8.1).

0

• 

  Dr Danish Ali

  • June 12, 2014 10:44

  I hit this problem back in August 2013 with an stm32f415 when I was playing around with low power sleep modes with all clocks stopped.

  Michael Johnson of Rowley started looking into it but we never found an explicit reason for the problem.

  The problem went away when I updated Crossworks to version 2.3.3 (Macintosh) - I see you are only on 2.3.2 so maybe this will help

  Where to find version 2.x? try http://www.rowley.co.uk/arm/releases.htm

  Hope this helps,

  Danish

  0

  Comment actions Permalink
• 

  Gordon Scott

  • June 12, 2014 11:39

  Hm, I see it's now on 3.1.1, so I'm well behind.

  I watch the installed packaged and assumed new versions would also appear there.

  Now seems a good time to update.

   

  0

  Comment actions Permalink
• 

  Jon Elliott

  • June 12, 2014 11:58

  In my experience you usually get this when your program has crashed and starts executing random debug I/O commands. The usual cause is stack corruption caused by allocating insufficient stack.

  Regards,

  Jon

  0

  Comment actions Permalink
• 

  Gordon Scott

  • June 12, 2014 12:57

  That's quite possible.

  I think I don't have stack problems, though I'll certainly check again.

  There are some other possible causes of a scrawler, though I usually protect my code pretty well to avoid these kinds of painful bugs.

  0

  Comment actions Permalink
• 

  Gordon Scott

  • June 12, 2014 15:44

  Well, it's unusual for me, but yes, I was overrunning a stack, so that's the likely cause.  We'll see.

  Thanks guys.

  0

  Comment actions Permalink

Please sign in to leave a comment.