Searching \ for '[PIC] Trouble debugging using MPLAB' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/languages.htm?key=mplab
Search entire site for: 'Trouble debugging using MPLAB'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Trouble debugging using MPLAB'
2010\07\02@174716 by David

flavicon
face
I have the following code: http://pastebin.ca/1890737 (the include files
are the standard HI-TECH libraries)

There is a bug with one of the I2C calls so I tried debugging using
MPLAB and my PICKit2 clone, but I cannot seem to get stepping working.

Of the various odd behaviours from MPLAB when trying to debug, I notice
the following:

- most often it will apparently free run, even with a breakpoint set on
line 41. Pausing it suggests that it is somewhere at the end of the
while loop (e.g. around line 113) but no serial data is ever actually
sent.  Looking at the SFR window the TRIS values are all wrong compared
to what is set in the code.

- sometimes (once or twice) it will not free run, claiming that
debugging has halted with the program counter at 0

- sometimes (once or twice) it hits a breakpoint on the first line of
code, but a single step seems to take approx. 1 minute and the little
green arrow that shows the current line of code disappears altogether

The toolbar is set to DEBUG not RELEASE.  The code works as expected if
compiled in release mode and programmed straight into the chip (i.e. the
error LED lights).  I have tried a new 18F2321 on a new board that I
soldered up specially.  I upgraded to the latest MPLAB and downloaded
the OS to my PICKit2 clone (but it was at the latest version already).

The disassembly window does have the correct C->ASM mapping and
breakpoints do get resolved.  I have tried creating an empty project and
starting again.

The integration of HI-TECH into MPLAB seems to be fine, as I can
compile/program correctly. But I cannot debug.

Has anybody seen symptoms like this before?  Any suggestions would be
appreciated.

David

2010\07\02@181622 by cdb

flavicon
face


:: Of the various odd behaviours from MPLAB when trying to debug

Which version of MPLAB and version/build of Hi-Tech C are you using? It
might be relevant.

Colin
--
cdb, spam_OUTcolinTakeThisOuTspambtech-online.co.uk on 3/07/2010

Web presence: http://www.btech-online.co.uk  

Hosted by:  http://www.1and1.co.uk/?k_id=7988359






2010\07\03@040532 by Wouter van Ooijen

face picon face
David wrote:
> I have the following code: http://pastebin.ca/1890737 (the include files
> are the standard HI-TECH libraries)

Maybe not related, but a program of mine worked OK with previous HiTech
(Lite), but failed with them latest. I located the problem to be a bug
in the code generation for the construct

   SPBRGH = ((spbrg) >> 8;

where spbrg is a literal larger than 255. changing it to

   SPBRGH = ((unsigned int)spbrg) >> 8;

solved the problem.

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2010\07\03@043018 by David

flavicon
face
On 02/07/2010 23:16, cdb wrote:
>
> :: Of the various odd behaviours from MPLAB when trying to debug
>
> Which version of MPLAB and version/build of Hi-Tech C are you using? It
> might be relevant.

Apologies, missing information.  I am using:

MPLAB v8.53
HI-TECH PICC PRO v9.63PL3 (in lite mode)
HI-TECH universal toolsuite v1.36

David

2010\07\03@043830 by David

flavicon
face
On 03/07/2010 09:05, Wouter van Ooijen wrote:
> David wrote:
>> I have the following code: http://pastebin.ca/1890737 (the include files
>> are the standard HI-TECH libraries)
>
> Maybe not related, but a program of mine worked OK with previous HiTech
> (Lite), but failed with them latest. I located the problem to be a bug
> in the code generation for the construct
>
>      SPBRGH = ((spbrg)>>  8;
>
> where spbrg is a literal larger than 255. changing it to
>
>      SPBRGH = ((unsigned int)spbrg)>>  8;
>
> solved the problem.

Thanks, I just checked this out.  I should make it clear that the
program does work and does send serial data (to Hyperterminal or a
receiving C# app) unless it it running in debug mode.  That's when I get
the whacky results.

I did check the HI-TECH serial library though to see how they setup the
registers: a #define is used to calculate the divider and SPBRG is set
using that.

David

2010\07\03@053648 by Wouter van Ooijen

face picon face
> I did check the HI-TECH serial library though to see how they setup the
> registers: a #define is used to calculate the divider and SPBRG is set

I was not referring to any specific location in your code. Just the fact
that a construct like this can cause trouble with this particular
version of the compiler, and in Lite mode. BTW the trouble was that the
bank switching instructions were emitting at the wrong place.

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2010\07\03@083617 by Isaac Marino Bavaresco

flavicon
face
Em 3/7/2010 05:05, Wouter van Ooijen escreveu:
> David wrote:
>> I have the following code: http://pastebin.ca/1890737 (the include files
>> are the standard HI-TECH libraries)
> Maybe not related, but a program of mine worked OK with previous HiTech
> (Lite), but failed with them latest. I located the problem to be a bug
> in the code generation for the construct
>
>     SPBRGH = ((spbrg) >> 8;
>
> where spbrg is a literal larger than 255. changing it to
>
>     SPBRGH = ((unsigned int)spbrg) >> 8;
>
> solved the problem.


According to C99 standard, right shift behavior of signed values is
implementation dependent. Perhaps Hi-Tech changed its behavior between
versions.

If 'spbrg' is a variable, it would be better if it is declared as unsigned.
If 'spbrg' is a macro (by convention its name should be all capitals)
define it with an 'u' at the end:
"#define SPBRG 1234u", for instance.

Then your code will survive porting to any platform.


Isaac

__________________________________________________
Fale com seus amigos  de graça com o novo Yahoo! Messenger
http://br.messenger.yahoo.com/

2010\07\03@134354 by Wouter van Ooijen

face picon face
> According to C99 standard, right shift behavior of signed values is
> implementation dependent. Perhaps Hi-Tech changed its behavior between
> versions.

I hope 'implementation dependent' does not allow poking the value into a
location in a different memory bank?

A quick google produces "It is up to the compiler implementation whether
0's (logical) or the sign bit (arithmetic) are shifted in as bits are
shifted to the right.". spbrg is a postitive value, so both
interpretations would produce the same result.

> If 'spbrg' is a variable, it would be better if it is declared as unsigned.
> If 'spbrg' is a macro (by convention its name should be all capitals)
> define it with an 'u' at the end:
> "#define SPBRG 1234u", for instance.

Actually it is a macro parameter :)

I don't agree with the 'macro's should be in capitals' convention, but
that's irrelevant here.

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2010\07\03@140458 by sergio masci

flavicon
face


On Sat, 3 Jul 2010, Wouter van Ooijen wrote:

> > If 'spbrg' is a macro (by convention its name should be all capitals)
>
> I don't agree with the 'macro's should be in capitals' convention, but
> that's irrelevant here.

Thank god! That's an absolutly stupid convention!

Many many years ago I read a book that pointed out that there should be no
difference between variables and constants. That you should be able to
switch between a variable and a constant by simply changing the
declaration of a symbol. That you should not need to go through a program
and change every occurance of a symbol because it has changed from a
constant to a variable or visa versa. This I thought was profound.
Similarly it follows that function names and macro names should be
interchangeable for the same reason.

Regards
Sergio Masci

2010\07\03@141105 by RussellMc

face picon face
> Many many years ago I read a book that pointed out that there should be no
> difference between variables and constants. That you should be able to
> switch between a variable and a constant by simply changing the
> declaration of a symbol. That you should not need to go through a program
> and change every occurance of a symbol because it has changed from a
> constant to a variable or visa versa. This I thought was profound.
> Similarly it follows that function names and macro names should be
> interchangeable for the same reason.

That would allow you to eg change a variable to a constant and then eg
increment or otherwise alter the constant's value.

You could probably just about do that in Apple II BASIC :-) - elsewhen
and elsewhere it's generally harder



                       Russell

2010\07\03@145155 by sergio masci

flavicon
face


On Sun, 4 Jul 2010, RussellMc wrote:

{Quote hidden}

No, not really. You could try, but the compiler would catch that as an
error.

The reason why you may want to do this may not be immediately obvious but
a possible example might be:

You start off using a constant because it's value can never change while
the program is running and using constants generates more efficient code.

somewhere along the line you change the constant to a variable so you can
change it's value at run time (tweak it during development).

Then you change it back to a constant and leave it that way until it needs
tweaking again.

>
> You could probably just about do that in Apple II BASIC :-) - elsewhen
> and elsewhere it's generally harder

Have you ever used FORTRAN? :-)

Regards
Sergio Masci

2010\07\03@150928 by RussellMc

face picon face
> Have you ever used FORTRAN? :-)

Lonnng ago.
Make that Long Long Lonnng ago.


   R

2010\07\03@164725 by sergio masci

flavicon
face


On Sun, 4 Jul 2010, RussellMc wrote:

> > Have you ever used FORTRAN? :-)
>
> Lonnng ago.
> Make that Long Long Lonnng ago.

Do you remember ever changing the value of a constant?

e.g.
http://everything2.com/title/Changing+the+value+of+5+in+FORTRAN

Regards
Sergio Masci

2010\07\03@172426 by Dario Greggio

face picon face
sergio masci ha scritto:
>
> Do you remember ever changing the value of a constant?
>
> e.g.
> http://everything2.com/title/Changing+the+value+of+5+in+FORTRAN


this is simply crazy :)
I'm glad I never used Fortran

--

Ciao, Dario
--
Cyberdyne

2010\07\03@180311 by Olin Lathrop

face picon face
Dario Greggio wrote:
>> http://everything2.com/title/Changing+the+value+of+5+in+FORTRAN
>
> this is simply crazy :)
> I'm glad I never used Fortran

It's not really that crazy, and not really the fault of Fortran either,
other than it didn't have subroutine prototypes.  Without knowing that TWEAK
could change its call argument, the compiler can't prohibit passing a
constant to it.  You could argue that not having subroutine prototypes is
crazy.  I would agree for a modern language, but Fortran being the first
real compiled computer language, "crazy" is rather unfair.  Sure, it looks
primitive from today's standpoint, but it was a real advance in its day.

Even without subroutine prototypes, this should be handled by putting the
literal pool in memory marked unwritable.  Nowadays we take that capability
for granted too, but Fortran ran on machines that didn't have that kind of
memory management.  Read/write attributes on chunks of memory tagged along
with memory management units designed to support virtual memory.

The early IBM 360s didn't have virtual memory.  If I remember right, the
first 360 with virtual memory was the 360/67 because it came with something
called a DAT (Dynamic Address Translation) box.  It's possible that many of
the machines Fortran ran on didn't have the capability of putting the
literal pool in a special section of memory so that unexpected writes to it
could be trapped.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2010\07\03@183030 by Carl Denk

flavicon
face
And things really went MAD right after Fortran came out:
http://en.wikipedia.org/wiki/MAD_%28programming_language%29

The manual had Alfred E. Newman's picture on the cover. :)

On 7/3/2010 6:03 PM, Olin Lathrop wrote:
{Quote hidden}

2010\07\03@183841 by David

flavicon
face
On 02/07/2010 22:47, David wrote:
> I have the following code: http://pastebin.ca/1890737 (the include files
> are the standard HI-TECH libraries)

In response to myself, I believe I have now fixed it.  Full details and
compile logs are on the HI-TECH forum at http://tinyurl.com/2vjjvbb

Essentially it appears to be reproducible bug that is fixed by opening
the Build Options dialog in MPLAB, toggling a random option on/off then
applying.  This seems to start it setting a bunch of extra compile
options which fix the debugging.

A very annoying little gotcha (perhaps not present if you upgraded, I
don't know) and I wouldn't have spotted it unless I spent an hour
clicking on random things :)

Cheers,

David

2010\07\04@164822 by Dario Greggio

face picon face
> On 7/3/2010 6:03 PM, Olin Lathrop wrote:
>> Dario Greggio wrote:
>>    
>>>> everything2.com/title/Changing+the+value+of+5+in+FORTRAN
>>>>        
>>> this is simply crazy :)
>>> I'm glad I never used Fortran
>>>      
>> It's not really that crazy, and not really the fault of Fortran either,
>> other than it didn't have subroutine prototypes.  Without knowing that TWEAK
>> could change its call argument, the compiler can't prohibit passing a
>> constant to it.  You could argue that not having subroutine prototypes is
>> crazy.  I would agree for a modern language, but Fortran being the first
>> real compiled computer language, "crazy" is rather unfair.  Sure, it looks
>> primitive from today's standpoint, but it was a real advance in its day.


:) I did not mean to say that Fortran as a whole is "crazy", but this
part surely is.
I also read the in-depth description about the issue. I agree with you
that "they were old times" and that those literals/variables could be
placed in ROM.

I am simply glad that I never used Fortran... so to say :) this is one
further argument about that. I faced a "mini" version back at C64 times,
and possibly I almost got to work to it in 1988 when working for a big
firm where PL/1 and Cobol were deeply in use (together with Oracle DB).
I did not like them all three.

Some months later, I got to know C and never left it :)

--

Ciao, Dario
--
Cyberdyne

More... (looser matching)
- Last day of these posts
- In 2010 , 2011 only
- Today
- New search...