View previous topic :: View next topic |
Author |
Message |
Woody
Joined: 11 Sep 2003 Posts: 83 Location: Warmenhuizen - NL
|
Problem with external interrupt on an 18F55Q43 |
Posted: Thu Oct 20, 2022 7:32 am |
|
|
Still my favorite chip. Learning the hard way :-)
Compiler v5.107
The problem:
I have a falling signal on PIN_D3 that refuses to generate an interrupt in my code.
Via PPS I mapped PIN_D3 to EXT1:
Code: |
#pin_select INT1=PIN_D3 // MP2667INT
|
The D port is valid for this mapping; the compiler has no problems with it, so I recon that the problem is not there.
if I use the standard CCS code
Code: |
enable_interrupts(INT_EXT1_H2L); // Enable mp2667 interrupt, High to low
|
I get this in the .lst file:
Code: |
.................... enable_interrupts(INT_EXT1_H2L); // Enable mp2667 interrupt, High to low
028C: BSF 4A4.0
028E: BCF 4D6.1
|
This turns out to be incorrect; the DS (page 180) has the PIE6 address that contains the INT1IE bit as 0x04AE. The other address for the edge selection is correct, 0x4DA6, INTCON0.
So I entered the right registers by hand:
Code: |
#byte PIE6 = 0x04AE
#bit INT1_EN=PIE6.0
#byte INTCON0 = getenv("SFR:INTCON0")
#bit INT1_EDG=INTCON0.1
// Enable interrupt
INT1_EN=1;
// Select H2L as edge
INT1_EDG=0;
|
this gives me the .lst file:
Code: |
.................... INT1_EN=1;
028C: BSF 4AE.0
....................
.................... // Select H2L as edge
.................... INT1_EDG=0;
028E: BCF 4D6.1
....................
|
Now I have the correct register and bit to enable the int2 interrupt. But it still does not work. The signal is there (scope), the isr is there :
Code: |
#INT_EXT1
void mp2667_int(void) {
led_b_timer = 0x2000;
}
|
Global interrupts are enabled. I have another interrupt (#INT_TIMER0) that works fine.
Is there a way to see what the compiler makes of the interrupt vector? Is there something else I missed?
Kind regards,
Paul |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19549
|
|
Posted: Thu Oct 20, 2022 11:45 am |
|
|
First thing to do is report the register error to CCS. They will probably
send you a fix in a couple of days.
The vector is fixed in the memory. Just look at the hex output to see what
is in the locations corresponding to the interrupt. However it should just be
the address of the handler. |
|
|
PrinceNai
Joined: 31 Oct 2016 Posts: 480 Location: Montenegro
|
|
Posted: Thu Oct 20, 2022 11:59 am |
|
|
In the datasheet I downloaded (page 192) INT1IE is bit 0 of PIE6, address is 0x04A4. Datasheet was downloaded today and it says it is a preliminary one.
You can see what interrupt handler does on your chip at address 8 in .lst file. I made a quick test project from your code and there it was located. |
|
|
Woody
Joined: 11 Sep 2003 Posts: 83 Location: Warmenhuizen - NL
|
|
Posted: Thu Oct 20, 2022 12:12 pm |
|
|
Well, at least part of this turns out to be a big brain fart of yours truly.
Somewhere else in my code I used setup_adc_ports(). Apparently if you don't use sANx for the port names this mucks up the command and some other ports. Fix that and my interrupt fired.
I am still baffled by one thing though; if I now use the original command
Code: |
enable_interrupts(INT_EXT1_H2L);
|
it works. I did renew my maintenance and upgraded the compiler to V5.110 this afternoon but the .lst file still reads a wrong register
I cannot find this 4A4 register in the entire DS (it is in a reserved range) so why this now works?
Before I start crying wolf to CCS I'll try to isolate this and see if that changes anything. Should have done that immediately.
Ttelmah, did you by chance check this register in the DS? |
|
|
Woody
Joined: 11 Sep 2003 Posts: 83 Location: Warmenhuizen - NL
|
|
Posted: Thu Oct 20, 2022 12:22 pm |
|
|
OK.
I need sleep. I loaded two datasheets next to each other in Foxit. Makes it easier to go back and forth between registers, settings etcetera
But it would have been SO handy if I had loaded the same datasheet twice, instead of one for the 18F25-45-55 and the other for the 18F04-05-14 that happened to be in the same directory......
I sincerely hope you guys did not spend too much time on this.
I feel like the idiot I am and will shut up.
Paul |
|
|
PrinceNai
Joined: 31 Oct 2016 Posts: 480 Location: Montenegro
|
|
Posted: Thu Oct 20, 2022 12:23 pm |
|
|
The important thing is that it works, no? Some blood in one's cheek never killed anyone :-) Welterusten |
|
|
Woody
Joined: 11 Sep 2003 Posts: 83 Location: Warmenhuizen - NL
|
|
Posted: Thu Oct 20, 2022 12:37 pm |
|
|
Thanks.
Very true. There's much worse sh*t going on than this and even from these silly mistakes I will learn :-)
Goodnight! |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19549
|
|
Posted: Fri Oct 21, 2022 12:39 am |
|
|
If I had a pound for every time I had accidentally switched to the wrong
data sheet!....
The setup_adc_ports one is a "head's up" one we will all have to remember.
Glad you have it working now.
This is why each project I do has it's own named directory. I put the data
sheet for the PIC in there, and also those for the other chips involved.
Then the schematics. The actual C project has a 'notes.h', which
contains no code, but notes on the connections, and problems I have found,
specific things like timing issues with chips etc.. That way when you come
back in ten years+, you can quickly remind yourself of things. This has paid
off so many times, when you get the phone call about a device you built
over forty years ago!.... |
|
|
Woody
Joined: 11 Sep 2003 Posts: 83 Location: Warmenhuizen - NL
|
|
Posted: Fri Oct 21, 2022 1:53 am |
|
|
Ttelmah wrote: | If I had a pound for every time I had accidentally switched to the wrong
data sheet!....
|
It is nice to know I am not the only human being :-)
Quote: |
This is why each project I do has it's own named directory. I put the data
sheet for the PIC in there, and also those for the other chips involved.
Then the schematics.
|
This is exactly what I do. The design phase of this project started out with the other chip (that was picked over the 25Q43 because of availability), then I ran out of IO, changed over to my favorite 55Q43 and forgot to remove the DS for the earlier chip.
The notes.h is a good idea; up to now I create a separate .odf file in an admin directory under the project, but a notes.h lives with the project.
I think that I have to resign myself to the fact that this is complicated stuff. Everything is new and potentially bugged. New design, in-house soldered prototype PCB, newish CPU, new components, new firmware. A gazillion reasons why something does not work as expected. And, weirdly enough, the one reason why I like what I do |
|
|
|