Searching \ for '[PIC] help! interesting behaviour of PI18F4520' 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/devices.htm?key=18F
Search entire site for: 'help! interesting behaviour of PI18F4520'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] help! interesting behaviour of PI18F4520'
2010\01\08@023958 by Tamas Rudnai

face picon face
(also added the PIC tag)

Hi Sergey,

Depending on the entire code your compiler could optimise the variable
out -- try to declare that variable as volatile. Check the HEX
(disassemble it or if ASM is generated analyse that one.

Also make sure your code was successfully programmed onto your chip.

Tamas


---------- Forwarded message ----------
From: Sergey Dryga <spam_OUTsergeyTakeThisOuTspamdryga.us>
Date: Fri, Jan 8, 2010 at 6:01 AM
Subject: help! interesting behaviour of PI18F4520
To: .....piclistKILLspamspam@spam@mit.edu


Hello all,

hope the collective brain has the answer.
Problem: unable to write to any variables
Setup:
PIC18F4520, CCS compiler v.3.242 (older version, but worked fine so far)
I have 2 almost identical boards (difference is type of solder used).  One board
performs as expected.  PIC on another has oscillator running, CCP/PWM module
works fine, I can change state of output pins (blink a led) when stepping
through the code.  But none of variable assignments work (e.g.

int i = 6;
while (i) {
output_toggle(LED);
i--;
};

does not assign or decrement i!)

I have replaced the PIC n that board,- still same behaviour.  I have not seen
this before and a bit stumped.  A solution could be to discard the board and
make another one, but I would like to find out reason for this.

Any hints/help is grreatly appreciated.

Thank you,

Sergey Dryga

2010\01\08@145501 by Sergey Dryga

flavicon
face

Tamas Rudnai <tamas.rudnai <at> gmail.com> writes:

{Quote hidden}

One board
> performs as expected.  PIC on another has oscillator running, CCP/PWM module
> works fine, I can change state of output pins (blink a led) when stepping
> through the code.  But none of variable assignments work (e.g.
<SNIP>


Hi Tamas,

Thanks for the reply (and adding the PIC tag).  
The code should be fine since it runs on another, identical, board.  
I'll verify that programming was successful, although I can step through the
code with debugger, and programmer reports everything OK.

Sergey

2010\01\08@162622 by Barry Gershenfeld

picon face
Is your debugger MPLAB? I was just reminded that CCS has their own debugger
also.  In MPLAB, if something has been optimized away, you won't be able to
set a breakpoint on it.  Also, you can View the File Registers and see the
variable there, and you can View the Program Memory window and watch it
execute the instructions machine code.  And a CCS thing, you can generate a
.lst file and see what it generated for each line of code.

>From your explanation, though, it sounds like somehow it is hardware.  We
got batch of boards here, where the 4 MHz crystal was 40 MHz instead.  That
can make lights look like they are not blinking; it can also cause
Read-Modify-Write problems that don't exist at the normal speed.

Oh, one more thing about the debugger.  I relies heavily on the generated
COFF file.  When in doubt, I recompile just to be sure everything is in
sync.

2010\01\08@175159 by Sergey Dryga

flavicon
face
Barry Gershenfeld <gbarry42 <at> gmail.com> writes:

>
> Is your debugger MPLAB? I was just reminded that CCS has their own debugger
> also.  In MPLAB, if something has been optimized away, you won't be able to
> set a breakpoint on it.  Also, you can View the File Registers and see the
> variable there, and you can View the Program Memory window and watch it
> execute the instructions machine code.  And a CCS thing, you can generate a
> .lst file and see what it generated for each line of code.
>
> >From your explanation, though, it sounds like somehow it is hardware.  We
> got batch of boards here, where the 4 MHz crystal was 40 MHz instead.  That
> can make lights look like they are not blinking; it can also cause
> Read-Modify-Write problems that don't exist at the normal speed.
>
> Oh, one more thing about the debugger.  I relies heavily on the generated
> COFF file.  When in doubt, I recompile just to be sure everything is in
> sync.

Thanks Barry,

I use CCS-ICD40 debugger/programmer and can step through and see variables in
the "watch" tab.  The problem is that I have 2 boards and PICs behave
differently with the same firmware.  That is what bugs me. The internal clock
runs at 8MHz on both chips, and CCP2/PWM frequency is the same.  
Is it possible that the PIC got zapped by static and shows this behavior?



2010\01\10@131109 by Gerhard Fiedler

picon face
Sergey Dryga wrote:

> I use CCS-ICD40 debugger/programmer and can step through and see
> variables in the "watch" tab.  The problem is that I have 2 boards
> and PICs behave differently with the same firmware.  That is what
> bugs me. The internal clock runs at 8MHz on both chips, and CCP2/PWM
> frequency is the same. Is it possible that the PIC got zapped by
> static and shows this behavior?

Something like this is always possible. When the votes are 1:1
(working/not working), you need a third voter (board) :)

Gerhard

2010\01\12@042830 by sergio masci

flavicon
face


On Fri, 8 Jan 2010, Sergey Dryga wrote:

{Quote hidden}

Check your software carefully looking for uninitalised variables. It is
just possible that on powerup the value of an uninitialised variable on
one PIC is safe while on another PIC it is unsafe.

Regards
Sergio Masci

2010\01\19@213150 by Sergey Dryga

flavicon
face
Gerhard Fiedler <lists <at> connectionbrazil.com> writes:

>
> Sergey Dryga wrote:
>
> > I use CCS-ICD40 debugger/programmer and can step through and see
> > variables in the "watch" tab.  The problem is that I have 2 boards
> > and PICs behave differently with the same firmware.  That is what
> > bugs me. The internal clock runs at 8MHz on both chips, and CCP2/PWM
> > frequency is the same. Is it possible that the PIC got zapped by
> > static and shows this behavior?
>
> Something like this is always possible. When the votes are 1:1
> (working/not working), you need a third voter (board) :)
>
> Gerhard

Following Gerhard's suggestion I made another board, and the votes are now 2:1
(working/not working).  My conclusion is that the batch of PICs I have is
damaged by static.  It turns out that my little son got them at one point and
played with them on carpet.

Thank you all for your help.

Sergey Dryga



2010\01\19@222118 by Funny NYPD

picon face
Is it possible just swap the chip? It could be board issue too.

Funny N.
Au Group Electronics, http://www.AuElectronics.com
http://www.AuElectronics.com/products
http://augroups.blogspot.com/




________________________________
From: Sergey Dryga <sergeyspamKILLspamdryga.us>
To: .....piclistKILLspamspam.....mit.edu
Sent: Tue, January 19, 2010 9:30:51 PM
Subject: Re: [PIC] help! interesting behaviour of PI18F4520

Gerhard Fiedler <lists <at> connectionbrazil.com> writes:

{Quote hidden}

Following Gerhard's suggestion I made another board, and the votes are now 2:1
(working/not working).  My conclusion is that the batch of PICs I have is
damaged by static.  It turns out that my little son got them at one point and
played with them on carpet.

Thank you all for your help.

Sergey Dryga



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