Problem with 16Ff648a

Printable View

- 10th November 2009, 15:27
aerostar

Problem with 16Ff648a

My program works 100% with 16F628A, using MCode V3.0.0.5, and PB, I re-compile for 16F648A and program but it does not even start.

If I compile for 16F628a and blow that into the 648A chip it works. Unless I have missed something, the only difference between the 628A and 648A is the memory ram and eeprom.

I have pinned the problem down to the CLEAR command ********.
No problem in the 628A, but fails in 648A

If I remove the CLEAR in the 648A it works, with it in, it doesn't.

I think maybe the CLEAR has a problem with the 648A somewhere.

Any suggestions/ideas greatfully received. Thanks

DEFINE OSC 20
@ device PIC16F648A,HS_OSC,BOD_ON,MCLR_ON

TRISA = 0
TRISB = 0

CS1 var PORTB.7 'Connect this to CS11 (set dip switchs to 1 = on 2/3/4 = off)
CS2 VAR PORTA.0
WR var PORTA.4 'connect this to wr ACTUALLY CLOCK BUT HOLTEK CALL IT MR
DATALINE var PORTA.1 'connect this to DATA

DEFINE HSER_TXSTA 20H
DEFINE HSER_RCSTA 90H
DEFINE HSER_BAUD 4800
DEFINE HSER_CLROERR 1 ' Clear error automatically when ncountered

MATRIXB VAR BYTE (72)
MATRIXA VAR BYTE (63)
CLOCK VAR BYTE(8)
PREVIOUSTIME VAR BYTE(8)
DATE var byte(6)
LOOP VAR BYTE ' FOR COUNTING
DIGITS VAR BYTE ' FOR COUNTING
COUNTER var byte ' FOR COUNTING
COUNTER2 var byte ' FOR COUNTING
ADDRESS var byte ' DISPLAY
COMD var byte ' DISPLAY
ENDBIT var bit ' DISPLAY
SENDDOTS var byte ' DOT COLUMN
NUMBER VAR BYTE ' USED TO SORT ALPHA AND NUMERIC
CLEAN VAR BYTE
TEMP VAR BYTE
TEMP2 VAR BYTE
START VAR BYTE
ENDLIST VAR BYTE ' USED IN LOOKUP TABLES
DISPLAY VAR BYTE 'USED FOR CHIP SELECTION

LONGTEMP VAR WORD
HOURSTENS VAR CLOCK(0)
HOURSUNITS VAR CLOCK(1)
COLON1 VAR CLOCK(2)
MINSTENS VAR CLOCK(3)
MINSUNITS VAR CLOCK(4)
COLON2 VAR CLOCK (5)
SECSTENS VAR CLOCK(6)
SECSUNITS VAR CLOCK(7)

DAYSTENS VAR DATE(0)
DAYSUNITS VAR DATE(1)
MONTHTENS VAR DATE(2)
MONTHUNITS VAR DATE(3)
YEARTENS VAR DATE(4)
YEARUNITS VAR DATE(5)

SCROLLSINGLE VAR BIT (8)

' FOLLOWING VARIABLES ARE FOR WHEN DAYLIGHT SAVING IS SWITCHED ON
GPSDAY VAR BYTE
GPSMON VAR BYTE
GPSYEAR VAR BYTE
STARTWKDAY VAR BYTE
A VAR BYTE
Y VAR BYTE
M VAR BYTE
D VAR BYTE
SUMMERTIMESWITCH VAR BYTE
MARDAY VAR BYTE
OCTDAY VAR BYTE
SUN VAR BYTE
CURRENTYEAR VAR BYTE

'SUMMER/WINTER SWITCH VALUES
DATA @64,0,0,0,0,1,1,1,1,1,1,1,0,0 '0 = GMT 1 = BST
' X J F M A M J U A S O N D 0 = WINTER 1 = SUMMER
' 0,0,0,0,1,1,1,1,1,1,1,0,0 X=0 MONTH NOT USED !

DATA @80,0 'HOURS OFFSET

CLEAR ' ALL VARIABLES TO 0 ******************

CMCON=7 ' SET PORT A DIGITAL
pause 1000
TEST:
low PORTB.7
PAUSE 250
HIGH PORTB.7
PAUSE 250
GOTO TEST
- 10th November 2009, 16:08
Charles Linquis

99 % of the time, if it works in one device, but not another the problem is in the configuration registers. The defaults don't always work for any given application.
- 10th November 2009, 16:18
Acetronics2

HI

Just cut and paste ...

replace LOOP for LOOP1 for PBP 2.60

...

Quote:

Success 84 Words used

So, this is not a chip problem ( I often use both chips ... no difference @ use )

BINGO ...
You should verify your Arrays declarations ... " illegal syntax " ...

Alain
- 10th November 2009, 19:25
aerostar

I knew about the LOOP variable and had changed its name for 2.60, and the result is the same, yes 84 words used, but it crashes, compiled with 2.43 or 2.6.

The configuration bits are the same for 628A and 648A, the only difference in these 2 chips is the extra memory size.

CLEAR is definately the problem, as if it is removed the program works, put it back and it does not. As far as I know CLEAR only writes zeros into all the declared memory locations and does nothing else

Perhaps someone at Melabs could give me the reason why removing CLEAR makes the program work.
- 10th November 2009, 22:51
mackrackit

Stupid question...
But are you changing this line as needed?
@ device PIC16F648A,HS_OSC,BOD_ON,MCLR_ON

And selecting the correct PIC at compile time?
- 11th November 2009, 08:52
aerostar

Quote:

Originally Posted by mackrackit

Stupid question...
But are you changing this line as needed?
@ device PIC16F648A,HS_OSC,BOD_ON,MCLR_ON

And selecting the correct PIC at compile time?

Yes.
PIC data sheet DS40044F, Page 1 says

pic 628a program words 2048, sram 224 bytes, eeprom 128 bytes,

pic 648a program words 4096, sram 256 bytes, eeprom 256 bytes,

As I said the ONLY difference between the 628A and 648A is the extra memory size, program, and EEprom, you can, as I have proved, put the hex file of the 628A into the 648A and it works. The compiled size for 628A is 77 bytes with PB2.43. Compile for the 648A and size is 84 words. ( extra words presumably to account for the bit extra memory)

I have now reduced the program to its simplest form for 648A, and before anyone else raises the configuration bits on programming, they are standard, HS,watchdog, power up timer, brownout, master clear reset are all selected, code protection off,and the correct pic.

*************PROGRAM 1 compiles to 51 words pb2.43 and pb2.6
DEFINE OSC 20
CHECKVARIABLE VAR BYTE

TEST:
LOW PORTB.7
PAUSE 250
HIGH PORTB.7
PAUSE 250
GOTO TEST

the above WORKS !

*********PROGRAM 2 with the CLEAR ADDED compiles to 73 words pb2.43 and pb2.6

DEFINE OSC 20
CHECKVARIABLE VAR BYTE
CLEAR
TEST:
LOW PORTB.7
PAUSE 250
HIGH PORTB.7
PAUSE 250
GOTO TEST

The above does NOT WORK.

you can even remove my CHECKVARIABLE and the results are the same.
eg
DEFINE OSC 20
CLEAR
TEST:
LOW PORTB.7
PAUSE 250
HIGH PORTB.7
PAUSE 250
GOTO TEST
does not work

So it still looks as though the CLEAR is causing the problem, CLEAR only writes zeros to all the ram memory space, so it does not matter whether you have variables declared or not.
- 11th November 2009, 10:10
Acetronics2

The ghost bug ....

Hi,

At the moment ...

I have my personnal 18 pins test board in front of me, Pic is a 16F648a, loaded with your program ( no mod ... )

you know what ??? ...

Led @ PortB.7 BLINKS !!!

Picture required ???

soooo ... try another '648 ... after checking your board and solders ...

Alain
- 11th November 2009, 11:23
Acetronics2

A '628 programmed with the '648 Hex file also works fine ...

Alain
- 11th November 2009, 15:51
aerostar

Quote:

Originally Posted by Acetronics

Hi,

At the moment ...

I have my personnal 18 pins test board in front of me, Pic is a 16F648a, loaded with your program ( no mod ... )

you know what ??? ...

Led @ PortB.7 BLINKS !!!

Picture required ???

soooo ... try another '648 ... after checking your board and solders ...

Alain

Hi Alain, thanks for the info, can you just confirm that you tried the 648A with the CLEAR.

The PCB is a commercially made board, currently in use, and just has the pic changed. I have tested 2 PCBs known working, with same result.

If yours does work, then I think there can only be 2 suspects left.

Suspect 1
The pics, I have tried 3 brand new ones, and all show the same problem, I have more but they are all the same batch, I will have to see if I can get a different batch.

Suspect 2
The programmer is not programming correctly, I use the Melabs EPIC programmer connected to LPT2, correct PSU and correct programming volts (re-checked this morning).

The EPIC programmer software is 2.46beta, latest for this from Melabs site. I have tried the Melabs programmer 4.32beta, but that does not work, it does not read the chip ID.

I will have to take the hex file to a friend tomorrow and get him to program the pic, at least that would rule out the programmer one way or another.

OH...... yes there is a final suspect.......................Me !!

Thanks all for your help.
- 11th November 2009, 17:04
Acetronics2

Hi,

Yes, was with the CLEAR command enabled ( I verified it was also in the Asm listing ...)

but, I begin to think your programmer doesn't set the config word correctly ... ( most common reason for such behaviour ... )

could you read back the config word of one of your PICs w/ the programmer ???

Alain
- 11th November 2009, 21:05
aerostar

Quote:

Originally Posted by Acetronics

Hi,

Yes, was with the CLEAR command enabled ( I verified it was also in the Asm listing ...)

but, I begin to think your programmer doesn't set the config word correctly ... ( most common reason for such behaviour ... )

could you read back the config word of one of your PICs w/ the programmer ???

Alain

The 648A works without the CLEAR and the config is correct when read back.

Also as earlier if I put the 628A hex file which has the CLEAR into the 648A pic it works, but not when compiled for 648A.

Tomorrow I will change the program so that it does a certain amount of loops to toggle the rb7 then put the clear and repeat the code and see if it stops after the clear, that way it would confirm that it is or is not something to do with the clear.

eg

toggle the port 20times*** if this works, programmer must be OK and pic
clear
toggle the port 20 times **** if it stops here then !!!!!!!
repeat sequence
- 11th November 2009, 23:13
Darrel Taylor

Quote:

Originally Posted by aerostar

... The EPIC programmer software is 2.46beta, latest for this from Melabs site.

That's the latest for epicwin, but it's not the latest for the epic programmer.

Try using meProg, which works with all the programmers ... epic, serial, U2 and Field programmers.
http://www.melabs.com/support/progsoft.htm
<br>
- 12th November 2009, 07:54
aerostar

Thanks Darrel, but I did say in my post at 15:51

Quote:

Originally Posted by aerostar

The EPIC programmer software is 2.46beta, latest for this from Melabs site. I have tried the Melabs programmer 4.32beta, but that does not work, it does not read the chip ID.

and will not even program the chip with the ID detect turned off.

More info when I do some more testing....
- 12th November 2009, 08:41
aerostar

Early morning test .........

After thinking about it overnight I wondered if the pic was not crashing but re-starting, so I put the following into the the pic, the porta loop lets me know that the program has started, and will let me know if the pic restarts.

With the CLEAR in between the portb loops it never executes the 2nd, but restarts the program ! as port A.0 starts toggling again.

Remove the CLEAR and it works as expected, so I will have to get a different batch of 648As to see if it is the pics.

DEFINE OSC 20

COUNTER VAR BYTE
FOR COUNTER = 0 TO 10 ' confirms beginning of program

LOW PORTA.0
PAUSE 250
HIGH PORTA.0
PAUSE 250
NEXT

TEST:

FOR COUNTER = 0 TO 20

LOW PORTB.7
PAUSE 250
HIGH PORTB.7
PAUSE 250
NEXT

CLEAR

FOR COUNTER = 0 TO 20

LOW PORTB.7
PAUSE 500
HIGH PORTB.7
PAUSE 500
NEXT

GOTO TEST
- 12th November 2009, 09:22
Darrel Taylor

Quote:

Thanks Darrel, but I did say in my post at 15:51 ... I have tried the Melabs programmer 4.32beta

Woops. My bad.
As soon as I see 2.46 beta, I stop looking for anything else.

I would be curious what happens with this program.
Since about the only difference between the 628A and 648A programs will be clearing the additional RAM in BANK2.

This program tries to clear the same memory without the clear statement.
It doesn't do banks 0 or 1 because they were already checked with the 628 program loaded in the 648.

Code:

DEFINE OSC 20 Idx VAR BYTE B2RAM VAR BYTE[80] BANK2 COUNTER VAR BYTE FOR COUNTER = 0 TO 10 ' confirms beginning of program LOW PORTA.0 PAUSE 250 HIGH PORTA.0 PAUSE 250 NEXT TEST: FOR Idx = 0 TO 79 B2RAM(Idx) = 0 NEXT Idx LOW PORTA.0 ' turn LED on to indicated completed ' may need HIGH don't know which way the LED is. STOP

Probably nonsense, but I'm still curious.
<br>
- 12th November 2009, 14:02
aerostar

Quote:

Originally Posted by Darrel Taylor

This program tries to clear the same memory without the clear statement.
It doesn't do banks 0 or 1 because they were already checked with the 628 program loaded in the 648.

Code:

DEFINE OSC 20 Idx VAR BYTE B2RAM VAR BYTE[80] BANK2 COUNTER VAR BYTE FOR COUNTER = 0 TO 10 ' confirms beginning of program LOW PORTA.0 PAUSE 250 HIGH PORTA.0 PAUSE 250 NEXT TEST: FOR Idx = 0 TO 79 B2RAM(Idx) = 0 NEXT Idx LOW PORTA.0 ' turn LED on to indicated completed ' may need HIGH don't know which way the LED is. STOP

Probably nonsense, but I'm still curious.
<br>

Hi Darrel

Thank you very much for the code, it works with no problem, I then modified it to check that after writing 0 to the location it was read back to see if it had been written correctly, answer is yes. I then made it keep doing, and again no failures.

Something is very strange. I have ordered some more 648As from another supplier, they may arrive tomorrow

I have just been looking through the listing and see that PB shows the following

16 =0020 RAM_START EQU 00020h
17 =01EF RAM_END EQU 001EFh
18 =0003 RAM_BANKS EQU 00003h
19 =0020 BANK0_START EQU 00020h
20 =007F BANK0_END EQU 0007Fh
21 =00A0 BANK1_START EQU 000A0h
22 =00EF BANK1_END EQU 000EFh
23 =0120 BANK2_START EQU 00120h
24 =01EF BANK2_END EQU 001EFh
25 =2100 EEPROM_START EQU 02100h
26 =21FF EEPROM_END EQU 021FFh

page 17 of my data sheet shows that bank 2 ends at 16FH not as it says above, 1EFH , could this be the problem or am I missing the obvious ?

What do you think ?

edit.

I have just changed the bank 2 end location to 16FH from 1EFH in the 648a.bas file and recompiled using the program in post 14, with the clear in position.......it works perfectly... so do you think I have found the problem ?
- 12th November 2009, 15:12
aerostar

Further update, on Bank end location, I have had a look at later version 2.61 files, my current one 2.43 I have used for many moons, and it looks as though the file may have been corrected in 2007, shows the value of updates, but then I would have thought someone would have noticed. I will try tomorrow with 2.61 and confirm that has no problems.
- 12th November 2009, 17:24
Darrel Taylor

That's definately it.

But you had said before ...

Quote:

but it crashes, compiled with 2.43 or 2.6.

Ha, we're even. :D
<br>
- 12th November 2009, 18:15
Acetronics2

where did I put my Beretta Balltrap Sporting gun and my buckshot cartdriges ???

I was thinking of BADRAM/MAXRAM ... but nooo... could not be possible to have been modified !!!

EVERYTHING is posssible ... LOL

Alain