18F14K50 External interrupt problem

[GTF]

Hello All,

I am not having much success on my first attempt with an external interrupt (RC0/INT0). I created the attached simple example to test this. If possible, I would like the interrupt to be triggered on the falling edges of the green trace. I would like the DAC output (yellow trace) to go low whenever the trigger signal is low (approximately 50 Hz) and continue on its normal path when the trigger signal is high. I want the synchronization to be tight (minimum delay possible). Time between the falling and rising edge is roughly 2.5msec. My actual full program loops at 500Hz or faster. The waveform of the yellow trace in the example has no significance other than to show that the DAC continues to be updated. Config bits are set in my USB bootloader. Is there an error in my flowchart, a conflict I am not aware of, or a possible hardware issue?

Thanks,
Grant

[GTF]

I had some success today after some fixes to the flowchart, but I was also using INT1 rather than INT0. Still have to swap back to INT0 to confirm that INT0 works.

[Benj]

Hello,

That's brilliant thanks for letting us know, I had a look at your signals from your first post but couldn't spot anything from them.

[GTF]

Thanks Benj. I also found that a suitable pull-down was required on the trigger signal line or it was not detected. In the tests shown that line was also connected with the + side of a pot, so I guess that provided the pull-down that I was missing.

[GTF]

Seems that I am still having trouble with this interrupt in my project. I added some LED flashes immediately at startup to check this and it appears that the interrupt triggers a reset. I do not see any fluctuation at the MCLR pin which has an external pullup. With the interrupt disabled and the INT1 pin still connected to the trigger signal, this does not happen. It also does not occur with the attached code even though the interupt is active. The main loop of my project code is very similar to this other than for more decisions, calculations and another ADC/switch read(I have tried both ways for the switch). All EEPROM activity occurs prior to the interrupt enable and main loop. The DAC output values are correct.

The green loop LED will not flash in the simulation unless the count limits are in single digits.

Could something in the code be causing the reset?

I just checked the config bits in the USB bootloader and I have STVREN enabled:
Config CPUDIV = NOCLKDIV
Config USBDIV = ON
Config FOSC = HS
Config PLLEN = ON
Config PCLKEN = OFF
Config FCMEN = OFF
Config IESO = OFF
Config PWRTEN = OFF
Config BOREN = OFF
Config BORV = 30
Config WDTEN = OFF
Config WDTPS = 32768
Config MCLRE = ON
Config HFOFST = ON
Config STVREN = ON
Config LVP = OFF
Config XINST = OFF
Config BBSIZ = OFF
Config CP0 = ON
Config CP1 = ON
Config CPB = ON
Config WRT0 = OFF
Config WRT1 = OFF
Config WRTB = ON
Config WRTC = ON
Config EBTR0 = OFF
Config EBTR1 = OFF
Config EBTRB = ON

Thanks,
Grant

[GTF]

I see that INT1 and INT2 need to have their priority bits set (INT0 is always high). I have been testing using INT1. I don't see this bit set in the generated C code and I only see the high priority vector in the relevant ASM code.

from C:
//Interrupt
//Interrupt: Enable RC1INT
cr_bit(intcon2, INTEDG1);
st_bit(intcon, GIE);
st_bit(intcon3, INT1IE);

from ASM:
ORG 0x00000800
GOTO _startup
ORG 0x00000808
GOTO interrupt

Do I need to add the following C code or similar?

st_bit(intcon3, INT1IP); // set INT1 high priority

Edit: I have tested this as well as using Int0 and it does not make a difference either way. INT1 and INT2 are set to high priority by default. It is still resetting or returning to startup/top of main after the interrupt.

[GTF]

Update for today:

I think this may be related to the bootloader as I do not see this strange behaviour without it. When using the bootloader I found that I had to add 2 output icons (0-->C4, 0-->C5) at the start of my code to get it to run properly. C4/C5 are my LED outputs. Adding any LED activity immediately before or after these 2 icons gets things messed up again (Interrupt returns to start of main).

Reviewing the bootloader, I was using C4 to turn on an LED and C2 (not C5) as the switch/jumper to enter bootloader mode. C2 is not used at all in my code. I am using INT0(C0) as the external interrupt pin. Though I don't really see anything in the bootloader up to and including the switch test that should cause a problem.

[GTF]

Today I did some minor housekeeping in the bootloader code, tested a couple of config bit changes, and commented the Low Interrupt vector lines (I notice that FC does not use this and it's code starts before this address. The chip also does not use this in the default "compatibility" mode). The BL was recompiled many times. Everything seems to be working OK now, but I cannot confirm what, if any, change helped as I can reverse each change and my FC code still behaves???

[Benj]

Hello,

Normally when using bootloaders there is a start vector to use to shift the program to a certain location, are you doing this at all in your Flowcode program?

To do this simple go to the Build -> Compiler options menu and go to the linker options.

In the linker parameters add this to the end of the line.

-rb 0x800

where 0x800 is the remap vector, Could be 0x1000 instead.

[GTF]

Hi Benj,

This is what I have for the linker options: -rb 0x800 -ld "C:\Program Files (x86)\Flowcode\v5\Tools\BoostC\lib" libc.pic16.lib rand.pic16.lib float.pic16.lib "%f.obj" -t PIC%p -d "%d" -p "%f"

This is the vector remap in the bootloader:
;Application FW RESET and INTERRUPT VECTORS
#define APP_RESET_VECTOR 0x000800
#define APP_HIGH_INTERRUPT_VECTOR 0x000808
#define APP_LOW_INTERRUPT_VECTOR 0x000818

There are goto's from the original vectors.

This is from my FC ASM code:
ORG 0x00000800
GOTO _startup
ORG 0x00000808
GOTO interrupt
ORG 0x0000080C
delay_us_00000
; { delay_us ; function begin
MOVF delay_us_00000_arg_del, F, 1
NOP
BNZ label1
RETURN

I have attached an image showing the start of the FC code hex without the BL loaded.

[GTF]

Here is the end of the BL hex without the FC hex loaded. I am using the Diolan encrypted bootloader which I adapted for this chip and to work without the extended instruction set (not that I have any prior coding knowledge).

[GTF]

Here is the FC hex and BL hex together after programming the FC hex to the chip with the bootloader.

[GTF]

Original FC hex on left. Same file on right after encrypt/decrypt without loading it to the chip. Does line 1 indicate that the BL will write a couple of bytes to 0x0000? I don't see any changes at that location after writing the file to the chip. And it reads back out the same(2 bytes from 0000). The rest of the hex is identical pre/post processing and this code runs OK. edit: After a bit more reading I see that line 1 of the right hand file is the extended linear address record(04) and not my FC data. So both files are identical. (Default is 0000)

I added some more code(a pair of decisions) to my project today and it started to behave erratically again. When I do a similar comparison for that file, there is also a difference at the end of the hex pre/post processing by the BL, in addition to the extra line at the beginning. edit: On closer inspection these lines are also the same. :0426C000EAFF11001C / :0826C000EAFF1100FFFFFFFF1C

So the encryption/decryption is good.

[GTF]

I have played with this a bit more and find that everything can be working perfectly until I add or remove some code to/from the chart. The ISR runs, but then the program seems to get lost on the return from the interrupt.

It appears to reset/restart from the start of the bootloader code (possible underflow/overflow) and it ends up stuck in my code in the loop to the right of this screenshot waiting for calibration to be initiated. It should never go there once already calibrated unless a failed re-calibration sequence has occurred...that sequence normally takes 15 seconds to run with LEDs flashing and requires user input.

[GTF]

If the bit of code I added here is functioning as intended, the STKFUL bit is set when the problem occurs. Not sure what is causing this as the external interrupt only calls a Macro that sets the value of a variable to 1 with no delays and this is the only macro created for the code (other than what I just added here for diagnostic purposes).

The code is updating to I2C devices and runs at about 5500HZ. The external interrupt occurs at about 55 HZ. There are no issues if the INT0 interrupt is not active.

[Kenrix2]

I didn't see any configuration settings in your attached program, maybe you could take a close look at your settings if you just left them blank for the attachment. Also, i don't think any software resets if your using them, like wdt, bor, reset, ect. will clear the stack, only a por will. A good place to start, at least for me if I am having trouble is to reread Medelec35's posts here:
http://www.matrixmultimedia.com/mmforum ... =26&t=6936
http://www.matrixmultimedia.com/mmforum ... 46&t=14095

[GTF]

Hi,
The configuration settings are set in the bootloader code as listed above. My actual application chart is more complex than the test code I posted, but I don't see anything that would cause uncontrolled stack growth and there are no compiler error messages.

Now, I don't even think it is related to the interrupt. I have the the main loop running fast enough now to detect the falling edge with an ADC read, so I eliminated the interrupt and still see this problem depending on what else I add or remove from the code. I can simply add another decision or remove one and the problem will return and go away. Even moving or removing the test of the STKFUL bit can upset things. A POR does clear that bit....I added code for LED flashes if the bit is set so it can be checked on a MCLR. There are no enabled pins that are floating, but now I am thinking that there may be some other instability that is upsetting things. I will put together a new board with a fresh chip and make a new 12V to 5V supply for the board, then see what happens.

The good thing is that this issue has resulted in a lot of learning.