/var/www/restricted/ssh/stm32/www/stm32circle/ STM CircleOS forum / Bug that makes Primer2 crash while debugging

Username:     
Password:     
             

Forum

# 1   2009-04-11 22:32:42 Bug that makes Primer2 crash while debugging

kubark42
Member
Registered: 2009-02-13
Posts: 46

Bug that makes Primer2 crash while debugging

I have a program that I'm trying to debug. When I arrive at a certain assembler step, RIDE says "Platform disconnected" (or something to that effect). This only occurs when optimizations are turned off. (I can't post the code here as the forum doesn't let me post files and it's much too long to paste in.)

Would a moderator like to take a look at my code and see if s/he can reproduce the bug? I figure it must be something bad to kick the debugger completely out, but, who knows, it might be PLBKAC.

Offline

 

# 2   2009-04-12 10:50:26 Bug that makes Primer2 crash while debugging

Francis
Administrator
From: France-Grenoble
Registered: 2007-07-09
Posts: 890

Re: Bug that makes Primer2 crash while debugging

Typically, it could happen if you disconnect the SWD connection, or if you power off the board. Would be surprized that the optimization level changes anything like that..

Offline

 

# 3   2009-04-12 12:12:10 Bug that makes Primer2 crash while debugging

kubark42
Member
Registered: 2009-02-13
Posts: 46

Re: Bug that makes Primer2 crash while debugging

To the best of my knowledge not doing anything like that. All I need to do to recover is simply start a new debugging session.

To make matters curiouser, this bug is occurring within a CirceOS file! Specifically, it's the LCD_Init routine while calling WriteData. It calls a simple write to the LCD screen, and at one particular spot it always fails.

[Edit. More info on the bug]

The exact assembler instruction that makes it fail is an STRH R3, [R2, #0x0, *2] as compiled from the LCD_SendLCDCmd. This command works fine for the WriteCOM instruction immediately  above, so I'm inclined to think it's something more than just a memory allocation problem, as this function does not return a value nor write to memory. The only thing it does is write to the LCD_CMD_MODE_ADDR address.

I'm willing to believe that this is user error somewhere, but how could that knock the debugger out?

I've made a backup copy of the code for later analysis. Any ideas?

Last edited by kubark42 (2009-04-12 12:40:58)

Offline

 

Board footer