| View previous topic :: View next topic |
| Author |
Message |
Langton
Joined: 29 Nov 2009
Posts: 25
|
| Register setting nightmares |
 Posted: Sun Oct 07, 2018 11:22 pm |
 |
|
Hi,
I have PCH 4.132 and MPLABX 4.2 on Windows 10.
PIC is a PIC18F25K80
I'm attempting to set BIE0 at 0xE7E
I've tried defining it with a #BYTE and #WORD and then associating a value to it in the code but in the disassembly, it always sets the value to mem address 0x7E instead of 0xE7E.
I've also tried setting it via individual bits etc, I'm just getting no-where with this, any help would be much appreciated |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19520
|
|
| Posted: Mon Oct 08, 2018 12:43 am |
|
|
It would. Remember this is an 8bit chip. Standard literal transfers use _page addressing_. The transfer is to be done as two 8bit transfers , and to address 0x7E/0x7F, in page 0xE.
So:
| Code: |
#word BIE0=0xE7E
void main()
{
BIE0 = 0xAA55; //dummy value for test
//results in:
.................... BIE0 = 0xAA55; //dummy value for test
0016: MOVLW AA //first byte
0018: MOVLB E //to page E - top byte of address
001A: MOVWF x7F //transfers to 0xE7F
001C: MOVLW 55 //second byte
001E: MOVWF x7E //to 0xE7E
|
Note this is a transfer to x7E, _not_ 0x7E. read the data sheet the MOVWF transfer is bank relative.
"Move data from W to register âfâ.
Location âfâ can be anywhere in the
256-byte bank."
There are transfers directly to a larger memory address (not using paging), but only from another memory address, and these take two instruction clock cycles each. So:
| Code: |
int16 val=0xAA55;
//gives:
0016: MOVLW AA
0018: MOVWF 06
001A: MOVLW 55
001C: MOVWF 05
//in the register initialisation, and then:
.................... BIE0=val;
001E: MOVFF 06,E7F
0022: MOVFF 05,E7E
|
|
|
|
Langton
Joined: 29 Nov 2009
Posts: 25
|
|
| Posted: Mon Oct 08, 2018 6:58 pm |
|
|
Thank you for your reply Ttelmah.
BIE0 is the CAN buffer interrupt enable register at address 0xE7E. It is just 8 bits wide. Previously when I've done something like...
#BYTE ODCON = 0xF91
and then...
ODCON = 0b00000001;
it will set reg 0xF91 to 0x01, but this just isn't working for BIE0. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19520
|
|
| Posted: Mon Oct 08, 2018 11:36 pm |
|
|
Well it is certainly setting it in the code I show. If it is byte wide, then you only need #byte. Your reference to using #word suggested you wanted 16bit access.
However I think you are getting confused by the use of 'x7E' in the assembler.. If you look, all values in the assembler are hex. They don't use 'x' as an indicator of hex, just as an indicator of an 'external' byte. The x in this case is what is put into the bank register. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Oct 09, 2018 12:26 am |
|
|
| Langton wrote: | | but this just isn't working for BIE0. |
Describe your testing method. Post your test program. How do you know
it's not working ?
In others, are you running this in Debug mode and stepping through
the code and looking at a Watch window ?
Or does your program not work correctly and you think it's this register ?
Describe your testing method.
------------------------------------------
The 18F25K80 data sheet has two notes on the BIE0 register. It says:
| Quote: |
REGISTER 27-60: BIE0: BUFFER INTERRUPT ENABLE REGISTER 0(1)
Note 1: This register is available in Mode 1 and 2 only.
Note 2: Either TXBnIE or RXBnIE in the PIE5 register must be set to get an interrupt.
|
What CAN mode are you operating in ? Mode 0 ? That would explain
why it doesn't work. The PIC defaults to using Mode 0. |
|
|
Langton
Joined: 29 Nov 2009
Posts: 25
|
|
| Posted: Tue Oct 09, 2018 1:42 am |
|
|
Hi Guys, thanks for the follow-up.
I did use the #BYTE to start with. In the assembler window, it showed FF (the value I want to set E7E to) being shifted to a variable name I was using that was located at address 7E. I was lead to this by the watch window via debugging to the processor through a Real Ice. I was trying to use Mode 1 as FIFO seemed a bit intense for me and I required more filters than Mode 0 had on offer. I am using CANRX1 interrupt. I'll piece together a test program tomorrow as I'm using my whole program which I've been migrating from Legacy to mode 1 with.
Thanks again for your input |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19520
|
|
| Posted: Tue Oct 09, 2018 2:36 am |
|
|
It's perhaps worth being aware that you can always just use a pointer:
| Code: |
#define BIEO 0xE7E
*(BIEO)=0b00000001;
|
Now you have got a very old compiler, and it is not too long after that chip was launched (I think it was first present in the low 4.12x compilers). There are often odd issues with 'new chips' for a few compiler versions, and it may be that 4.132, does not think there is any memory at 0xE7E that can actually be addressed. The pointer mode avoids this checking. I don't actually have this version, since there were so many issues with the compilers around here, that I didn't keep them all. However 4.128, merrily accepts:
#byte BIE0 = 0xE7E
BIE0 = 0b00000001;
and generates:
| Code: |
.................... BIE0 = 0b00000001;
0030: MOVLW 01
0032: MOVLB E
0034: MOVWF x7E
|
Which is correct.
Are you sure your debugger understands page addressing?.... |
|
|
Langton
Joined: 29 Nov 2009
Posts: 25
|
|
| Posted: Tue Oct 09, 2018 4:13 pm |
|
|
hi guys.
| Ttelmah wrote: |
Are you sure your debugger understands page addressing?....
|
I have no idea how I would even check that. I assume being a Microchip Real Ice it must as I've had no issues with it thus far.
So I made a cut-down program e.g.
| Code: |
#include <18F25K80.h>
#fuses NOWDT,BROWNOUT,NOPLLEN,NOIESO,NOFCMEN,PUT,SOSC_DIG,CANB,protect,DEBUG,NOMCLR
#use delay(clock=20M, crystal)
#include <CAN_inc.c>
#define BIE0 0xE7E //getenv("SFR:BIE0")
void main()
{
*(BIE0) = 0b11111111;
while (1==1)
{}//while
}//main
|
and the BIE0 set perfectly, I confirmed the disassembly was also correct.
| Code: | ! *(BIE0) = 0b11111111;
0xA7A: MOVLB 0xE
0xA7C: SETF 0x7E, BANKED
|
so I went back to the full program and got, as usual...
| Code: |
0x2A30: MOVLB 0xE
0x2A32: SETF buttondelay, BANKED
! *(BIE0) = 0b11111111;
|
So I wondered if the problem is, as soon as I have a variable at 0x7E, it all goes south. So I added #reserve 0x7E
and then got
| Code: |
0x2A30: MOVLB 0xE
0x2A32: SETF 0x7E, BANKED
! *(BIE0) = 0b11111111;
|
Now, interestingly, the Real Ice does not show BIE0 changing BUT the simulator does. So at this point I'm unsure if the problem is the silicon or Real Ice. I'll pursue it today by attempting to read the BIE0 register with some debug code and see how I go.
Thanks again for your assistance. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19520
|
|
| Posted: Wed Oct 10, 2018 1:16 am |
|
|
OK. MPLAB-X is up well into V5 now.
In the 'IDE issues' page from MicroChip, there is a hit for 'bank selection issue' for your ICE and V4.2. I suspect this is what you are seeing... |
|
|
Langton
Joined: 29 Nov 2009
Posts: 25
|
|
| Posted: Wed Oct 10, 2018 3:36 am |
|
|
Thank you very much Ttelmah.
I've tried google'ing it without much luck. If you have a chance, would I be able to grab a link? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19520
|
|
| Posted: Wed Oct 10, 2018 3:45 am |
|
|
Whether I can find it again is interesting!...
It was a document from Microchip for the IDE, listing issues on a per release basis. It gave them by date rather than version number, but the date looked about right for 4.2 (early this year). |
|
|
Langton
Joined: 29 Nov 2009
Posts: 25
|
|
| Posted: Thu Oct 11, 2018 3:30 pm |
|
|
Alrighty, thanks heaps Ttelmah, I'll hunt it down when I get a moment.
For now, I'll run with Legacy and just live with the higher throughput of the mask/filters.
Appreciate the help guys, thanks heaps  |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
