CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Problem with external interrupt on an 18F55Q43

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Woody



Joined: 11 Sep 2003
Posts: 75
Location: Warmenhuizen - NL

View user's profile Send private message

Problem with external interrupt on an 18F55Q43
PostPosted: Thu Oct 20, 2022 7:32 am     Reply with quote

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: 19195

View user's profile Send private message

PostPosted: Thu Oct 20, 2022 11:45 am     Reply with quote

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: 452
Location: Montenegro

View user's profile Send private message

PostPosted: Thu Oct 20, 2022 11:59 am     Reply with quote

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: 75
Location: Warmenhuizen - NL

View user's profile Send private message

PostPosted: Thu Oct 20, 2022 12:12 pm     Reply with quote

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
Code:

028C:  BSF    4A4.0


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: 75
Location: Warmenhuizen - NL

View user's profile Send private message

PostPosted: Thu Oct 20, 2022 12:22 pm     Reply with quote

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......Embarassed

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: 452
Location: Montenegro

View user's profile Send private message

PostPosted: Thu Oct 20, 2022 12:23 pm     Reply with quote

The important thing is that it works, no? Some blood in one's cheek never killed anyone :-) Welterusten
Woody



Joined: 11 Sep 2003
Posts: 75
Location: Warmenhuizen - NL

View user's profile Send private message

PostPosted: Thu Oct 20, 2022 12:37 pm     Reply with quote

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: 19195

View user's profile Send private message

PostPosted: Fri Oct 21, 2022 12:39 am     Reply with quote

If I had a pound for every time I had accidentally switched to the wrong
data sheet!.... Sad

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: 75
Location: Warmenhuizen - NL

View user's profile Send private message

PostPosted: Fri Oct 21, 2022 1:53 am     Reply with quote

Ttelmah wrote:
If I had a pound for every time I had accidentally switched to the wrong
data sheet!.... Sad

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 Very Happy
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group