Searching \ for '[PIC] Weirdness with 16F628A' 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=16F
Search entire site for: 'Weirdness with 16F628A'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Weirdness with 16F628A'
2007\09\24@015500 by David Duffy

flavicon
face
part 1 962 bytes content-type:text/plain; charset=windows-1250 (decoded 7bit)

Hi there,
It's been some time since I've needed the assistance of this list but
I've come up against an odd problem. It's probably something really
simple (stupid) but it's got me stumped.

I'm working on a small project using assembler and a 16F628A-I/P. The
code simulates perfectly but when run on the acutual chip, it spins off
into program space when I call the routine at the end of my asm file and
seems to wrap around to the beginning of the program. I can see some
pins that I toggle at startup just continually doing so.

Things I've checked are:
   I'm not fiddling with the PCL
   All the code fits in under about 0x2ce
   The watchdog is not turned on

When I move the routine in question dow to the "front of the code" it
works, but then the new one at the end fails. These routines are direct
copies from another project of mine which works perfectly. Can anyone
suggest anything please?
David...



part 2 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

2007\09\24@022109 by Tech

flavicon
face
part 1 1296 bytes content-type:text/plain; (decoded 7bit)

{Quote hidden}

If execution wraps around to the beginning, I would guess you have no return or
goto at the end or last routine to return to your main loop.

Or you have something causing a device reset.

Regards,

-Bruce
http://www.rentron.com


part 2 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

2007\09\24@025959 by Forrest W. Christian

flavicon
face
part 1 803 bytes content-type:text/plain; charset=windows-1250; format=flowed (decoded 7bit)

David Duffy wrote:
> When I move the routine in question dow to the "front of the code" it
> works, but then the new one at the end fails. These routines are direct
> copies from another project of mine which works perfectly. Can anyone
> suggest anything please?
Are you sure you're wrapping around?  Have you considered adding some
"debugging output" at the end of memory to ensure it is rolling
around?   It also occurs to me that depending on your code, it could be
that you're somehow being redirected to the interrupt vector from a
toggling pin.

Are you able to use the ICD debugging stuff?   That might help you
figure out what is going on there.

I've also seen power supply stability cause brownout resets....

-forrest


part 2 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

2007\09\24@044117 by Dario Greggio

face picon face
tech@rentron.com wrote:

> If execution wraps around to the beginning, I would guess you have no return or
> goto at the end or last routine to return to your main loop.

yeah, or Stack Overflow?...

--
Ciao, Dario

2007\09\24@050024 by Snail Instruments

flavicon
face

> > If execution wraps around to the beginning, I would guess you
> have no return or
> > goto at the end or last routine to return to your main loop.
>
>yeah, or Stack Overflow?...

But all these problems should be recognized by the simulator.

Uninitilized variables could be likely cause. Or set of input data,
which was not simulated.

Josef

2007\09\24@062618 by cdb

flavicon
face
Hi David,

I don't see why, but is the CMCON register causing a problem perhaps?
Have you tried a different 628a from a different batch?

Does the uC use sleep - there is an errata for some silicon, causes unexpected program execution.

Perhaps the config word is corrupted when programming?


I've had a similar problem with a 648, which disappeared when I used a different compiler and the ASM by both looked OK, so must have been a hex file corruption.

Colin
--
cdb, spam_OUTcolinTakeThisOuTspambtech-online.co.uk on 24/09/2007

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

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







--
No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.488 / Virus Database: 269.13.30/1025 - Release Date: 9/23/2007 1:53 PM


2007\09\24@071301 by David Duffy (AVD)

flavicon
face
Thanks guys. I've combined all the questions and answers to save bandwidth.

> I don't see why, but is the CMCON register causing a problem perhaps?
>  

I'm disabling the comparators as per many other projects.

> Have you tried a different 628a from a different batch?
>  

Yes, three different batches. I'll check with a "non-A" version tomorrow.

> Does the uC use sleep - there is an errata for some silicon, causes unexpected program execution.
>  

No sleep involved. (especially for me!)

> Perhaps the config word is corrupted when programming?
> I've had a similar problem with a 648, which disappeared when I used a different compiler and the ASM by both looked OK, so must have been a hex file corruption.
>  

Maybe something to check. I may have to reinstall an older version of
MPLAB although thinking about it I used the same version, PC and
PicStart+ to do the other (working) project.

> Uninitilized variables could be likely cause. Or set of input data,
> which was not simulated.

No inputs really. All variables are cleared before use.

> Stack Overflow?...

Only 2 levels deep at the time of the problem. Not an underflow either
says the simulator.

> Are you sure you're wrapping around?  Have you considered adding some
> "debugging output" at the end of memory to ensure it is rolling
> around?   It also occurs to me that depending on your code, it could
> be that you're somehow being redirected to the interrupt vector from a
> toggling pin.

Actually, I tried a sleep instruction or setting a diagnostic pin at
0x7ff but it doesn't actually seem to roll through there. I'm not really
sure where it's jumping to now!

> Are you able to use the ICD debugging stuff?   That might help you
> figure out what is going on there.

I do have an ICD but have never learned to use it. The board is not
setup for ICP either. :-(

> I've also seen power supply stability cause brownout resets....

Checked PSU and all pins for out-of-spec voltage and instability using
DMM and CRO.

> If execution wraps around to the beginning, I would guess you have no return or
> goto at the end or last routine to return to your main loop.
>  

No missing returns that I can see. No calls instead of goto's or
visa-versa either.

> Or you have something causing a device reset.

It is indeed getting back to the reset vector as I can see the start-up
code executing every xx (will have to measure) milliseconds. It's very
regular but watchdog is off at present. That was my first thought.

The odd thing is the delay routine that's playing up works perfectly
when I move it closer to the front of the code. Then the routine(s) at
the end go west. It's as if no routine itself is faulty, but the
execution is!
David...

2007\09\24@084543 by Tamas Rudnai

face picon face
> The odd thing is the delay routine that's playing up works perfectly
> when I move it closer to the front of the code. Then the routine(s) at
> the end go west. It's as if no routine itself is faulty, but the
> execution is!

So it was not the case with the PCLATH thingy?

BTW: Is not it OSCCAL value at 7FF? Your programmer might not even let you
place a code over there to avoid overwriting the OSCCAL value like that. Try
to put this diagnostic sniplet before - like turn on a pin and "goto $"
would do as it 'should not be happen'.

Tamas



On 9/24/07, David Duffy (AVD) <.....davidKILLspamspam@spam@audiovisualdevices.com.au> wrote:
{Quote hidden}

> -

2007\09\24@191954 by David Duffy (AVD)

flavicon
face
Tamas Rudnai wrote:
>> The odd thing is the delay routine that's playing up works perfectly
>> when I move it closer to the front of the code. Then the routine(s) at
>> the end go west. It's as if no routine itself is faulty, but the
>> execution is!
>>    
>
> So it was not the case with the PCLATH thingy?
>
> BTW: Is not it OSCCAL value at 7FF? Your programmer might not even let you
> place a code over there to avoid overwriting the OSCCAL value like that. Try
> to put this diagnostic sniplet before - like turn on a pin and "goto $"
> would do as it 'should not be happen'.
>  

Good point. I'd forgotten about the trim for the internal RC in this chip.
I just added a diagnostic pin BSF (and wait loop) at 0x7f0 and it still
resets.
David...

2007\09\25@045800 by Tamas Rudnai

face picon face
Do you have testing routine in the reset area so that you can find out what
type of reset you have?
Can you show the code especially how you call that routine?

Tamas


On 9/25/07, David Duffy (AVD) <davidspamKILLspamaudiovisualdevices.com.au> wrote:
{Quote hidden}

> -

2007\09\25@233232 by David Duffy (AVD)

flavicon
face
Both TO and PD indicate that a wdt or wake from sleep has not occurred.
All I'm doing is calling the affected routine like this:

start:
bank0 ;start in ram bank 0
call clear_ram ;
call initialise ;initialise registers, etc
bsf l_red ;turn red led on
call delay_250 ;wait 250ms
bcf l_red ;turn red led off
...

It's spinning off into space during the delay_250 routine.
David...

Tamas Rudnai wrote:
> Do you have testing routine in the reset area so that you can find out what
> type of reset you have?
> Can you show the code especially how you call that routine?
>  

2007\09\26@043158 by James Hillman

flavicon
face
> Both TO and PD indicate that a wdt or wake from sleep has not occurred.
> All I'm doing is calling the affected routine like this:
>
> start:
> bank0 ;start in ram bank 0
> call clear_ram ;
> call initialise ;initialise registers, etc
> bsf l_red ;turn red led on
> call delay_250 ;wait 250ms
> bcf l_red ;turn red led off
> ...
>
> It's spinning off into space during the delay_250 routine.

Could an interrupt be occurring during the delay - a timer perhaps
inadvertently set-up during initialise?

In the initialise routine have you used code intended for a different
processor that may have had Special Function registers in different banks to
the processor you are now using?

Does any bank switching occur during the delay?
Does it go 'spinning off' after a specific time ( you could reduce the delay
until you find this )

Just some ideas, thoughts for you

James

2007\09\26@043826 by Tamas Rudnai

face picon face
Hi David,

I think I've mentioned that it could be that you might call routines in a
different page, have you tried to do this modification?

> start:
> bank0 ;start in ram bank 0
> call clear_ram ;
> call initialise ;initialise registers, etc
> bsf l_red ;turn red led on

 pagesel delay_250    ; This will select the correct page of the program
memory for CALL (by setting PCLATH)

> call delay_250 ;wait 250ms
> bcf l_red ;turn red led off

Tamas



On 9/26/07, David Duffy (AVD) <.....davidKILLspamspam.....audiovisualdevices.com.au> wrote:
{Quote hidden}

> -

2007\09\26@054316 by cdb

flavicon
face
David,

Have checked BOR?

It might be worth reading the hex file back and see if it compares with the original - UltraEdit32 can compare and report differences.

Colin

:: Both TO and PD indicate that a wdt or wake from sleep has not
:: occurred.

--
cdb, EraseMEcolinspam_OUTspamTakeThisOuTbtech-online.co.uk on 26/09/2007

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

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

Even if faith is lacking, and hope is non existent, you always have charity and compassion to offer.





--
No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.488 / Virus Database: 269.13.30/1030 - Release Date: 9/25/2007 8:02 AM


2007\09\26@063443 by David Duffy (AVD)

flavicon
face
James Hillman wrote:
>> Both TO and PD indicate that a wdt or wake from sleep has not occurred.
>> All I'm doing is calling the affected routine like this:
>>
>> start:
>> bank0 ;start in ram bank 0
>> call clear_ram ;
>> call initialise ;initialise registers, etc
>> bsf l_red ;turn red led on
>> call delay_250 ;wait 250ms
>> bcf l_red ;turn red led off
>> ...
>>
>> It's spinning off into space during the delay_250 routine.
>>    
>
> Could an interrupt be occurring during the delay - a timer perhaps
> inadvertently set-up during initialise?
>  

I've disabled GIE and the fault persists.

> In the initialise routine have you used code intended for a different
> processor that may have had Special Function registers in different banks to
> the processor you are now using?
>  

No, init routine taken from a known good project using the same chip.

> Does any bank switching occur during the delay?
> Does it go 'spinning off' after a specific time ( you could reduce the delay
> until you find this )

No bank switching in the delay routine.
David...

2007\09\26@063542 by David Duffy (AVD)

flavicon
face
Tamas Rudnai wrote:
> Hi David,
>
> I think I've mentioned that it could be that you might call routines in a
> different page, have you tried to do this modification?
>  

That was my first thought but the 16F628A only has one code page.
David...

2007\09\26@063929 by David Duffy (AVD)

flavicon
face
cdb wrote:
> David,
>
> Have checked BOR?
>
> It might be worth reading the hex file back and see if it compares with the original - UltraEdit32 can compare and report differences.
>  

Hi Colin,
Didn't check BOR but BOD is off. Will check DOR and POR anyway.
I've just downloaded MPLAB 6.60 to see if it's a programming bug.
David...

2007\09\26@064921 by Tamas Rudnai

face picon face
Ok, so assume what we know:

1. calling delay_250 succeed - it goes to the right address
2. it starts a loop or something and while its doing this your PIC resets?
3. there is no interrupt at all
4. it looks like a Power On Reset? (definitely no any other type of reset)
5. no code escape (aka the debug glitch is not occured when put it to the
end of the prog memory.

Tamas



On 9/26/07, David Duffy (AVD) <davidspamspam_OUTaudiovisualdevices.com.au> wrote:
{Quote hidden}

> -

2007\09\26@181415 by David Duffy (AVD)

flavicon
face
cdb wrote:
> Hi David,
>
> I've had a similar problem with a 648, which disappeared when I used a different compiler and the ASM by both looked OK, so must have been a hex file corruption.
>  

Well, I downloaded MPLAB 6.60 and it now works! MPLAB 7.62 is screwing
with it somehow. The bad version verifies so it must be down to the
assembler version? I'm downloading MPLAB 7.50 now to see what happens.
David...

--
___________________________________________
David Duffy        Audio Visual Devices P/L
Unit 8, 10 Hook St, Capalaba 4157 Australia
Ph: +61 7 38235717   Fax: +61 7 38234717
New Web: http://www.audiovisualdevices.com.au
___________________________________________

2007\09\26@203403 by Marcel Duchamp

picon face
David Duffy (AVD) wrote:
> cdb wrote:
>> Hi David,
>>
>> I've had a similar problem with a 648, which disappeared when I used a different compiler and the ASM by both looked OK, so must have been a hex file corruption.
>>  
>
> Well, I downloaded MPLAB 6.60 and it now works! MPLAB 7.62 is screwing
> with it somehow. The bad version verifies so it must be down to the
> assembler version? I'm downloading MPLAB 7.50 now to see what happens.
> David...
>

Can you assemble your code by both 6.60 & 7.62 and compare the output
listings to see if there are differences?  This would very interesting
to know about.  The list gets postings every month or two about code
that appears broken until the poster goes back to an earlier version of
MPLAB.

It's so easy to develop blind faith in your tools, isn't it?  I know I
do this.

2007\09\26@210709 by Jinx

face picon face
> I've had a similar problem with a 648, which disappeared when I
> used a different compiler and the ASM by both looked OK, so
> must have been a hex file corruption.

Several times I've noticed that MPASM doesn't pick up on typos.
The most recent was when I used, from memory, the variable name
op_stat. The compilation appeared to go OK. However, the real
variable name I should have used was o_stat. Took lots of debugging
to find that where op_stat had been used, there was no code made.
For example movf op_stat,w was simply ignored. Replacing op_stat
with o_stat fixed it all. Perhaps you should check carefully for typos

(apologies if I've forgotten the original problem)

2007\09\26@221952 by David Duffy (AVD)

flavicon
face
Jinx wrote:
>> I've had a similar problem with a 648, which disappeared when I
>> used a different compiler and the ASM by both looked OK, so
>> must have been a hex file corruption.
>>    
>
> Several times I've noticed that MPASM doesn't pick up on typos.
> The most recent was when I used, from memory, the variable name
> op_stat. The compilation appeared to go OK. However, the real
> variable name I should have used was o_stat. Took lots of debugging
> to find that where op_stat had been used, there was no code made.
> For example movf op_stat,w was simply ignored. Replacing op_stat
> with o_stat fixed it all. Perhaps you should check carefully for typos
>
> (apologies if I've forgotten the original problem)
>  

The problems are now gone that I've "downgraded" to MPLAB 7.50 although
installing more than one version of MPLAB at the same time (to different
directories) caused a few problems. You really need to remove the
original one and then install the new one. I'm back to coding the
(overdue) app so haven't had a chance to check more into it yet.
David...

2007\09\27@082918 by Bob Axtell

face picon face
Jinx wrote:
>> I've had a similar problem with a 648, which disappeared when I
>> used a different compiler and the ASM by both looked OK, so
>> must have been a hex file corruption.
>>    
>
> Several times I've noticed that MPASM doesn't pick up on typos.
> The most recent was when I used, from memory, the variable name
> op_stat. The compilation appeared to go OK. However, the real
> variable name I should have used was o_stat. Took lots of debugging
> to find that where op_stat had been used, there was no code made.
> For example movf op_stat,w was simply ignored. Replacing op_stat
> with o_stat fixed it all. Perhaps you should check carefully for typos
>
> (apologies if I've forgotten the original problem)
>
>  
The worst problem I noticed was old MPASM not handling "pagesel"
properly. That drove me crazy until
I finally found it. I simply created my OWN pagesel macro, which I used
for a couple of years, until I noticed
that MC had finally fixed it.

When I  commented on it later on PICLIST, nobody had even noticed the error.

BTW, I am unable to use anything later than 7.40 for my ICD2's on my
XPs. Lord only knows what the problem is.

--Bob

2007\09\27@090707 by Tamas Rudnai

face picon face
I don't know either but that's the reason I still use 7.41 - not sure what
is the diff between the 7.40 and this but it just works perfect for me.
Sometimes I'm using the GPASM toolset as it generates a COD file that makes
it possible to debug macros - even in MPSIM.

But one thing i surely could not understand is that if the code was ok in
simulator why or how was that behaving different in real world? I mean if
that is a compiler bug? Would love to see the disassembled code compared to
the working one.

Tamas



On 9/27/07, Bob Axtell <@spam@engineerKILLspamspamcotse.net> wrote:
{Quote hidden}

> -

2007\09\27@094154 by Dave Wheeler

flavicon
face
The last time I had a similar problem it was down to the .hex format.
From memory the earlier versions of MPASM defaulted to INHX8M where the
more recent versions default to INHX32. This can easily be checked in
the project properties and by comparing the .hex files produced.

Cheers

Dave


Tamas Rudnai wrote:
{Quote hidden}

>> --


'[PIC] Weirdness with 16F628A'
2007\10\01@170834 by Barry Gershenfeld
face picon face

>  The code simulates perfectly but when run on the acutual chip, it spins off
>into program space when I call the routine at the end of my asm file and
>seems to wrap around to the beginning of the program.
>
>     All the code fits in under about 0x2ce
>
>When I move the routine in question dow to the "front of the code" it
>works, but then the new one at the end fails.

End of the program missing?  In the old days I used to manually set the
programming range, because it programmed the chip faster if the program is
small.  I shot myself in the foot numerous times; using yours as an example
I'd have the program size erroneously set to 027F.  These days MPLAB
probably warns you.  I gave up that practice after a few of these.  And the
"A" processors and the ICD2 both make for faster programming anyway.

Barry

2007\10\01@183511 by David Duffy (AVD)

flavicon
face
Barry Gershenfeld wrote:
>>  The code simulates perfectly but when run on the acutual chip, it spins off
>> into program space when I call the routine at the end of my asm file and
>> seems to wrap around to the beginning of the program.
>>
>>     All the code fits in under about 0x2ce
>>
>> When I move the routine in question dow to the "front of the code" it
>> works, but then the new one at the end fails.
>>    
>
> End of the program missing?  In the old days I used to manually set the
> programming range, because it programmed the chip faster if the program is
> small.  I shot myself in the foot numerous times; using yours as an example
> I'd have the program size erroneously set to 027F.  These days MPLAB
> probably warns you.  I gave up that practice after a few of these.  And the
> "A" processors and the ICD2 both make for faster programming anyway.
>  

I wonder if that's what was going wrong? I didn't manually set the end
point but maybe MPLAB was setting it incorrectly. I'll see if I can
duplicate the error on another machine that still has the newer version
installed.
David...

--
___________________________________________
David Duffy        Audio Visual Devices P/L
Unit 8, 10 Hook St, Capalaba 4157 Australia
Ph: +61 7 38235717      Fax: +61 7 38234717
Our Web Site: http://www.audiovisualdevices.com.au
___________________________________________

2007\10\01@210247 by Xiaofan Chen

face picon face
On 9/27/07, Bob Axtell <RemoveMEengineerTakeThisOuTspamcotse.net> wrote:
> BTW, I am unable to use anything later than 7.40 for my ICD2's
> on my XPs. Lord only knows what the problem is.
>

Most of the people have no problems with original ICD2 and proper
ICD2 clone with V7.62. What is your ICD2 model? Is it original or a
clone one?


Xiaofan

2007\10\02@075629 by Bob Axtell

face picon face
Xiaofan Chen wrote:
> On 9/27/07, Bob Axtell <spamBeGoneengineerspamBeGonespamcotse.net> wrote:
>  
>> BTW, I am unable to use anything later than 7.40 for my ICD2's
>> on my XPs. Lord only knows what the problem is.
>>
>>    
>
> Most of the people have no problems with original ICD2 and proper
> ICD2 clone with V7.62. What is your ICD2 model? Is it original or a
> clone one?
>
>
> Xiaofan
>  
It was an original. But I later noticed that the XPs are all HOME
Editions.. maybe that makes the difference?

--Bob A

2007\10\02@100153 by Xiaofan Chen

face picon face
On 10/2/07, Bob Axtell <TakeThisOuTengineerEraseMEspamspam_OUTcotse.net> wrote:
> > Most of the people have no problems with original ICD2 and proper
> > ICD2 clone with V7.62. What is your ICD2 model? Is it original or a
> > clone one?
>
> It was an original. But I later noticed that the XPs are all HOME
> Editions.. maybe that makes the difference?
>

Should not make any differences. You might want to try a bit
harder. But I know ICD2 is a bit fragile and I do not like it
at all...

2007\10\02@100558 by Xiaofan Chen

face picon face
On 10/2/07, Xiaofan Chen <RemoveMExiaofancspamTakeThisOuTgmail.com> wrote:
> On 10/2/07, Bob Axtell <engineerEraseMEspam.....cotse.net> wrote:
> > > Most of the people have no problems with original ICD2 and proper
> > > ICD2 clone with V7.62. What is your ICD2 model? Is it original or a
> > > clone one?
> >
> > It was an original. But I later noticed that the XPs are all HOME
> > Editions.. maybe that makes the difference?
> >
>
> Should not make any differences. You might want to try a bit
> harder. But I know ICD2 is a bit fragile and I do not like it
> at all...
>

By the way, if you only use PIC12F/16F/18F, PICkit 2 can do
pretty much anything ICD2 can do. With MPLAB 8.0 on the
way, PICKit 2 debugging should be quite good.

And PICkit 2 is a better programmer than ICD2 IMHO.
Comaprison of PICKit 2 and ICD2:
http://forum.microchip.com/tm.aspx?m=282776
PICkit 2 website: http://www.microchip.com/pickit2


Xiaofan

2007\10\02@103822 by Tamas Rudnai

face picon face
On 10/2/07, Bob Axtell <EraseMEengineerspamcotse.net> wrote:
>
> It was an original. But I later noticed that the XPs are all HOME
> Editions.. maybe that makes the difference?
>


For me later versions than 7.41 of MPLAB just does not do the job right, and
I have an enterprise version of XP. After that they started to use .NET
stuff (AFAIK only for programmers/debuggers?) but I had problem with MPSIM
actually. I have always the latest patch from Microsoft as it is policy here
in the workplace - and have Norton AV if that counts?

(Just received a new laptop with Vista business edition, will try on that -
will install Microsoft SteadyState first, just in case :-))

Tamas

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