Searching \ for 'MPASM bug ?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page:
Search entire site for: 'MPASM bug ?'.

Truncated match.
PICList Thread
'MPASM bug ?'
1997\08\20@072615 by Mark Dennehy

picon face
Hi all ...
I'm just starting out with the PIC chip so if this is a silly question,
scratch it up to the learning curve :)

I'm writing a small routine to test the serial line connection (232c
using a max232 and the usart on the 16c74a) but Mpasm keeps giving me
the 'incorrect bank' error message (#302). Here's the code chunk -
anyone know if this is my code or mpasm ?

;  Serial line test program

#include ""

#define ClkFreq  20000000
#define baud(X)  ((10*ClkFreq/(64*X))+5)/10 -1
#define TXSTA_INIT 0xA0
#define RCSTA_INIT 0x90

org 0

RESET call Setup_Async_Mode
 call Send_Serial_Data_Poll

org 032
  bcf  STATUS,RP1
  bsf  STATUS,RP0
  movlw baud(9600)
  movwf SPBRG                ;MPASM gives error #302 here ...
  movlw TXSTA_INIT
  movwf TXSTA               ;... and here
  movlw RCSTA_INIT
  bcf  STATUS,RP0
  movwf RCSTA

PollTxmt btfss PIR1,4
  goto PollTxmt
  movlw 'X'
  movwf TXREG
  goto Send_Serial_Data_Poll

Mark Dennehy, B.A., B.A.I.  Email :
Research Student,
Computer Vision and Robotics Research Group,
Computer Science Dept., Trinity College Dublin

1997\08\20@080900 by Andrew Warren

Mark Dennehy <.....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU> wrote:

> I'm just starting out with the PIC chip so if this is a silly
> question, scratch it up to the learning curve :)

   It's not a silly question, Mark... It gets asked all the time.

{Quote hidden}

   Strictly speaking, the error's in your code... Although this
   section of your program will assemble correctly and work as you

   Here's what's happening:

   SPBRG and TXSTA are, as you know, located on register-page 1;
   the PIC16C74A.INC file equates them to 0x99 and 0x98,

   The numbers 0x98 and 0x99 are 8 bits wide, but if you look at
   your PIC16C74 data shet, you'll see that the MOVWF instruction
   only has room for a SEVEN-bit register number.

   This, of course, is why you need to set the RP0 bit before
   accessing registers on page 1, and clear it before accessing
   registers on page 0; RP0 holds the eighth bit of the register


   When you write "MOVWF SPBRG" (or "MOVWF 0x99"), MPASM notices
   that you're trying to force an eight-bit register number into a
   space only large enough to hold seven bits, so it builds the
   instruction using only the low seven bits of the register number
   (0x19, in this case) and generates Warning #302 to inform you.

   Your code will assemble and work fine, since you really only WANT
   the "MOVWF" insruction to hold the low seven bits of the register
   number, but if you really want to do it RIGHT, you should change
   your "MOVWF SPBRG" and "MOVWF TXSTA" instructions to:

       MOVWF   SPBRG^080H      ; The "^080H" masks off the high bit
                               ; of the register number.


      MOVWF   TXSTA^080H      ; The "^080H" masks off the high bit
                              ; of the register number.

   Of course, you can also just turn off the warnings by putting an
   "ERRORLEVEL -302" line near the start of your program.


=== Andrew Warren -
=== Fast Forward Engineering - Vista, California

=== For PICLIST help (including "unsubscribe" instructions),
=== put the single word "help" in the body of a message and
=== send it to:

1997\08\20@082325 by Fred Thompson

       Check you .lst file.  It probably says something like:

Message[302]: Register in operand not in bank 0.  Ensure that bank bits
are correct.

       My program is full of these things and it gets to be a little
annoying.  If you check the code generated, you will probably see that it
made the right numbers.  It just spits out this warning to highlight
places where you could make a mistake (I saw in your listing that you did
       If you get your serial I/O working, I would be VERY interested in
seeing your code.  I wrote an interrupt based routine that does not
receive.  For a complete listing of my code, see the archive.  You can
search by name (Fred Thompson), or by date (Wed 13 Aug, 1997).

Fred Thompson

1997\08\20@203818 by Darrel Johansen

picon face
Andrew Warren wrote:
> Mark Dennehy <PICLISTspamspam_OUTMITVMA.MIT.EDU> wrote:
> > I'm just starting out with the PIC chip so if this is a silly
> > question, scratch it up to the learning curve :)
>     It's not a silly question, Mark... It gets asked all the time.

Thanks, Andy, for clarifying this one.... again.    :-)

On this same topic, there is are two reasons for defining SFR's and
variables with values greater than 7 bits.
 1. You can use variable names while debugging MPLAB in the Modify
      window or in the Execute Opcode dialog.
 2. You can use the new MPASM directives described below.

In the latest beta version of MPASM (v1.99.xx) there are new
directives, one called BANKSEL.  Originally designed for use with the
Linker and relocatable code only, it also now works for
non-relocatable output code from MPASM.

This allows you to do the bank switching to access an SFR or
RAM variable without actually having to toggle the specific bank
bits (there's also BANKISEL for indirect addressing, and PAGESEL
for ROM paging).

When making relocatable code the addresses of RAM variable may not be
known until the Linker is invoked, there needs to be a way to set up
the proper RAM bank page.  This is done like this:
     banksel myvar
     movwf   myvar
The Linker will generate the proper bit-banging bank instructions for
processor currently set with the MPASM P directive...  So if you move
your code from a processor that has two RAM banks to one that has
four, or even if you move it from a 16C54 to a 16C84, the proper
banking code will be generated.

If you are not generating relocatable code (using the /o option with
MPASM), then MPASM will expand the BANKSEL directive to the proper
instructions.  You may want to use
     ERRORLEVEL -302
to suppress those MPASM messages that are distracting, or as Andy also
suggested, AND the operand to strip off the extra bits.

Darrel Johansen

1997\08\21@112524 by Lynn Richardson

At 12:14 PM 8/20/97 +0100, you wrote:
{Quote hidden}

Message 302 is not an error message. It is a warning.  If you have
correctly set RP0, ignore it.  Or you can disable it by putting:

       ERRORLEVEL      -302

in the beginning of your source file.

Lynn Richardson - Design Eng.|WA0ZNL            |Progress Instruments, Inc.
DC - 1GHz, RX, TX 100W, PLL  |WA0ZNL.AMPR.ORG   |807 NW Commerce Drive
ASM 6805, 8051, Z8, PIC      |       |Lee's Summit, MO 64086
C                            ||P(816)524-4442 F 246-4556

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