Continue to Site

# pic16F628 to pic6F628A

Status
Not open for further replies.

#### Wp100

##### Well-Known Member
Hi,

Have got an assembler program for a 628 chip that builds, programs and runs in circiut ok.

I'm trying to run it on the more available 628A chips, which as far as I can see just needs the new Osc and Boren config words changing as well as the Pic statement. ( comparator not used )

When I build the 628A (with mplab 8.30) I get the following message -
Error - section '.org_3' can not fit the absolute section. Section '.org_3' start=0x00000004, length=0x00000fe2 "
( org_1 eeprom x2100 , org _2 Start x0000 )

I have removed some text messages from the code and rebuilt and still got the same message but with ' length -x00000F6A '

Being as the 2K memory should allow to 0x0000FFF I'm a bit lost as to whats happening ??

Any help apprieciated,

Thanks

#### be80be

##### Well-Known Member
you have the org set wrong
org 0x000
or cblock 0x20

#### Wp100

##### Well-Known Member
Hi,

Think the orgs are ok, they are unchanged from the proven 628 to the new 628A - the datasheets list them as identical memory addresses and sizes.

Ram starts at 0x20 and is in bank0 only - just .50 bytes

Code:
 org    0x2100           ;Preset address in EEROM
org     0x000
Begin   goto    Start
org     0x004	;interrupt vector (not used)
goto    Begin

To me its saying the code is larger than the memory, but when you have 0x0FFF avaliable how can 0x0FE2 or 0x0F6A be too large ?

#### be80be

##### Well-Known Member
your org is wrong you have org 0x2100 then org 0x000 you should have something like this
Code:
	list      p=16f628A           ; list directive to define processor
#include <p16F628A.inc>       ; processor specific variable definitions

errorlevel  -302              ; suppress message 302 from list file

__CONFIG   _CP_OFF & _DATA_CP_OFF & _LVP_OFF & _BOREN_OFF & _MCLRE_ON & _WDT_OFF & _PWRTE_ON & _INTOSC_OSC_NOCLKOUT
cblock 0x20
d1
endc

org	0x0000			;org sets the origin, 0x0000 for the 16F628,
;this is where the program starts running
main:
movlw	0x07
movwf	CMCON			;turn comparators off (make it like a 16F84)

bsf 	STATUS,		RP0	;select bank 1
movlw 	b'00000000'		;set PortB all outputs
movwf 	TRISB
movlw 	b'00000001'
movwf	TRISA			;set PortA all outputs
bcf	    STATUS,		RP0	;select bank 0

this goes at the end
Code:
; initialize eeprom locations

ORG	0x2100
DE	0x00, 0x01, 0x02, 0x03

END                       ; directive 'end of program'
not before the main org 0x000

Post you whole code at least to the main

Last edited:

#### Wp100

##### Well-Known Member
Hi,

The code is not mine, and the guy who gave it to me does not want it distrubuting.

To me all the memory addressed look correct - like I have alway used myself.
I have also always be told to load the EEprom directive using Orgx2100 before the main code - not at the end ?? - its worked properly on 16and 18F chips for me for years.

I have the 628 code (well proven over some years ) in mplab now, with the pic specified as 628 it builds ok, change the pic type and mplab select device to 628A and you get the memory size error.

Given that the chips are said to be compatible why does it give such an error when there seems to be space free ?

I can take out the org 2100 eprom and the org 004 but the message just changes down to Error Org_1

Just an update - missed an obvious thing - of course the 628/A chips only have 07FF bytes of prom - so it seems when I build at a 628A its generating twice the amount of code to say it cannot fit the 0FD2 into the 07FF space.

Have just built the same code first as 628 ok then but the 628A gives the Org error ??

Last edited:

#### Nigel Goodwin

##### Super Moderator
Hi,

The code is not mine, and the guy who gave it to me does not want it distrubuting.

To me all the memory addressed look correct - like I have alway used myself.
I have also always be told to load the EEprom directive using Orgx2100 before the main code - not at the end ?? - its worked properly on 16and 18F chips for me for years.

I've never heard of any such suggestion, and it seems a really silly thing to do - why not do it in the order that it goes in?.

However, it won't make any difference, as the whole point of the ORG command is to set the address.

I have the 628 code (well proven over some years ) in mplab now, with the pic specified as 628 it builds ok, change the pic type and mplab select device to 628A and you get the memory size error.

Given that the chips are said to be compatible why does it give such an error when there seems to be space free ?

I can take out the org 2100 eprom and the org 004 but the message just changes down to Error Org_1

The error is probably because you're trying to assemble an absolute addressed program as a relative one.

Run MPASMWIN (the MicroChip assembler) directly (not from MPLAB) and load the assemblty file into that, it will probably work fine then.

#### Wp100

##### Well-Known Member
Hi Nigel,

Don't know if you saw the edit to my last post before you posted.

The code is built in Absolute , did try AsmWin direct but that just came up with parameter errors .???

Seems when I switch to the 628A it wants to generate twice the code yet the assembler code shows a 3815 lines of code when built as the 628 or 628A

Strange that this proven 628 code won't build when coded as 628A ? - sure it must be somthing I've missed but what ?

Regarding the Org EEprom location; would not have remembered something like that if I had not told by what I thought was a good source, which would have been the Microchip forum back then, although a lot of examples including this guys code do specify it before the main code ?

#### be80be

##### Well-Known Member
This is the only changes from a 16f628 to 16f628a
This section describes the functional and electrical
specification differences when migrating between functionally
similar devices. (such as from a PIC16F627 to
a PIC16F627A).
C.1 PIC16F627/628 to a PIC16F627A/628A
1. ER mode is now RC mode.
2. Code Protection for the Program Memory has
changed from Code Protect sections of memory
to Code Protect of the whole memory. The Configuration
bits CP0 and CP1 in the PIC16F627/
628 do not exist in the PIC16F627A/628A. They
have been replaced with one Configuration
bit<13> CP.
3. “Brown-out Detect (BOD)” terminology has
changed to “Brown-out Reset (BOR)” to better
represent the function of the Brown-out circuitry.
4. Enabling Brown-out Reset (BOR) does not automatically
enable the Power-up Timer (PWRT)
the way it did in the PIC16F627/628.
5. INTRC is now called INTOSC.
6. Timer1 Oscillator is now designed for
32.768 kHz operation. In the PIC16F627/628
the Timer1 Oscillator was designed to run up to
200 kHz.
7. The Dual Speed Oscillator mode only works in
the INTOSC Oscillator mode. In the PIC16F627/
628 the Dual Speed Oscillator mode worked in
both the INTRC and ER Oscillator modes.

#### Nigel Goodwin

##### Super Moderator
Hi Nigel,

Don't know if you saw the edit to my last post before you posted.

The code is built in Absolute , did try AsmWin direct but that just came up with parameter errors .???

Seems when I switch to the 628A it wants to generate twice the code yet the assembler code shows a 3815 lines of code when built as the 628 or 628A

Strange that this proven 628 code won't build when coded as 628A ? - sure it must be somthing I've missed but what ?

Post the code then, or a link to where it's from, so we can try it.

Regarding the Org EEprom location; would not have remembered something like that if I had not told by what I thought was a good source, which would have been the Microchip forum back then, although a lot of examples including this guys code do specify it before the main code ?

I don't think I've ever seen an example where the data memory was specified before the program code? - it's such a weird and pointless idea.

I can only imagine you're confused by the normal practice of putting data tables in the first page of memory?.

#### be80be

##### Well-Known Member
When I build the 628A (with mplab 8.30) I get the following message -
Error - section '.org_3' can not fit the absolute section. Section '.org_3' start=0x00000004, length=0x00000fe2 "
( org_1 eeprom x2100 , org _2 Start x0000 )

This tells you that you are building as absolute and that org3 can't fit .

Build for relocatable code

And what I'm saying about org is Microchips template shows it this way
Code:
;***** VARIABLE DEFINITIONS
cblock  0x20

org 0x000 ;main
;then
org 0x004 ;interrupt vector location
;then  initialize eeprom locations which is at the end of code
ORG	0x2100

Last edited:

#### Wp100

##### Well-Known Member
Hi,

This is the only changes from a 16f628 to 16f628a

Yes, thanks Burt, have already printed those docs out.

Edit - just the same error message when built as relocatable.

Nigel
Post the code then, or a link to where it's from, so we can try it.

As metioned earlier its not my code and the owner sent me a copy of the assembler on the understanding I did not distrubute it as it could have some commercial worth.
Would have asked for his help but he is away till the end of the month.

It must be one of those 'silly' errors on my part, will try again tomorrow and will let you know what it was if I crack it.

Last edited:

#### Wp100

##### Well-Known Member
Hi Mike

I've never activley used Linker so know little about it other than its general function.

The code does not contain any script commands other than the include for the 628A.
There are no other linker script files attached to the project.

If I turn off the Linker in the MPASM suite folder and build it with MPLIB it does build ok. but of course no .hex file.

Out of interest I took the asm file to work and ran a new project on a pc that still had MPlab 8.10 ( using 8.30 at home) - this time the code built ok as both the 628 and 628A with Linker On.

So as you say it seems to be something to do with linker but what it is and how I overcome it I'm afraid I'm at a total loss ?

Any help welcome !

#### blueroomelectronics

##### Well-Known Member
Why not ask the fellow who gave the code to reassemble it for you?

#### Nigel Goodwin

##### Super Moderator
Hi Mike

I've never activley used Linker so know little about it other than its general function.

The code does not contain any script commands other than the include for the 628A.
There are no other linker script files attached to the project.

If I turn off the Linker in the MPASM suite folder and build it with MPLIB it does build ok. but of course no .hex file.

Out of interest I took the asm file to work and ran a new project on a pc that still had MPlab 8.10 ( using 8.30 at home) - this time the code built ok as both the 628 and 628A with Linker On.

So as you say it seems to be something to do with linker but what it is and how I overcome it I'm afraid I'm at a total loss ?

Any help welcome !

Like we've said all along, it looks like you're trying to build it as relocatable code, when it's absolute code - using MPASMWIN on it's own should do it correctly, as it's absolute only.

#### Wp100

##### Well-Known Member
Hi Nigel,

Just had another try at AsmWin, it didn't work last night because I browsed and picked up the full path to the file, but it repeatedly gave Parm error - just entering test.asm and it works ? - and it builds fine, - thanks.

When I'm using Mplab 8.30 it most certainly is in Absolute mode I've tried selecting the 'generate absolute code' and also the 'ask me' so I click on absolute code when it asks me during the build.

I'm still at a loss as to know why the code works in Mplab 8.30 as a 628 chip, but just changing the code to a 628A with the correct OSC config and it gives the error ?? As I said earlier, at work today, under Mplab 8.10 it builds fine for both versions ?

Status
Not open for further replies.

Replies
16
Views
2K
Replies
12
Views
3K
Replies
10
Views
949
Replies
2
Views
746
Replies
5
Views
814