0
\$\begingroup\$

I'm debugging a code for the Microchip PIC18F4520 using the PROTEUS ISIS. The code was compiled with the C18 compiler. There is a very crazy bug in the code that I don't know whether it is my fault or an ISIS/PIC problem. The imagem below shows the problem.

At the function 'free', before the statement at address 1004 is executed the variable 'i' has the value 0. When the instruction is executed, the variable 'i' magically receives the value 125.

The 'heap_status' is a global variable that has no binding with the variable 'i'.

Why assigning a value to 'heap_status' affects the variable 'i'?

PS.: When the function is executed for the first time, this doesn't happen. The problem arises when the function executes for the second time.

debug

asked Dec 15, 2014 at 1:23
\$\endgroup\$
9
  • 2
    \$\begingroup\$ What optimization level are you using when compiling? \$\endgroup\$ Commented Dec 15, 2014 at 4:39
  • \$\begingroup\$ The c18 optimization options shows: Enable All. But when I build the project, the output shows: "C:\Program Files (x86)\Microchip\mplabc18\v3.47\bin\mcc18.exe" -p18F4520 -ms -oa- -o- -I "C:\Program Files (x86)\Microchip\mplabc18\v3.47\bin"\\..\\h -fo build/default/production/_ext/32825281/misc.o "C:/Users/user/Desktop/EngCompTemp/8_fase/SOemb/Trabalho I/SO.X/misc.c" MPLAB C18 3.47 (feature limited) Copyright 2000-2011 Microchip Technology Inc. This version of MPLAB C18 does not support the extended mode and will not perform all optimizations. \$\endgroup\$ Commented Dec 15, 2014 at 11:02
  • \$\begingroup\$ I disabled all the optimizations and the problem persists. \$\endgroup\$ Commented Dec 15, 2014 at 11:10
  • \$\begingroup\$ Your parameter for the function is pointer to void. Why? Are you sure you are using it the right way? The bug sounds very odd, and I can't think of anything else. Mayve you cast a gifferent pointer type to void * and use it as another type? \$\endgroup\$ Commented Feb 11, 2015 at 6:14
  • 1
    \$\begingroup\$ Given the number of people who can't read your images, could you please post actual code? that would be easier for us to copy/paste & try out, rather than having to run an image through OCR first ;-) \$\endgroup\$ Commented Nov 29, 2018 at 14:35

1 Answer 1

1
\$\begingroup\$

Without seeing your code it's difficult to give advice (your screenshot is too small to read). What you see can be typically attributed to dynamic memory or auto variables when at certain point the debugger will (erroneously) show you the stack location previously occupied by a variable defined inside a function. Move the code inside a function to see if it makes a difference.

answered Jan 12, 2015 at 3:18
\$\endgroup\$

Your Answer

Draft saved
Draft discarded

Sign up or log in

Sign up using Google
Sign up using Email and Password

Post as a guest

Required, but never shown

Post as a guest

Required, but never shown

By clicking "Post Your Answer", you agree to our terms of service and acknowledge you have read our privacy policy.