18F47K42 UART interrupt keep on triggering

18F47K42 UART interrupt keep on triggering

Postby 32768hertz » Fri Jan 03, 2020 6:24 pm

Setup: 18F47K42 receives through RX a continuous stream of data from another microcontroller just for test
LATAbits.LA0 simulates a normal running program, to see if something is executed, not shown in the picture but it never blinks
LATAbits.LA4 triggers when any interrupt
LATAbits.LA5 triggers only when data is in RX buffer, ready to be read (this part apparently seems to work ok).
but for some reason, something else keeps on triggering the interrupt

Image
this is the code.

Code: Select all
#include <pic18f47k42.h>

#pragma config FEXTOSC = LP // External Oscillator Selection (LP (crystal oscillator) optimized for 32.768 kHz; PFM set to low power)
#pragma config RSTOSC = HFINTOSC_64MHZ// Reset Oscillator Selection (HFINTOSC with HFFRQ = 64 MHz and CDIV = 1:1)
#pragma config CLKOUTEN = OFF // Clock out Enable bit (CLKOUT function is disabled)
#pragma config PR1WAY = OFF // PRLOCKED One-Way Set Enable bit (PRLOCK bit can be set and cleared repeatedly)
#pragma config CSWEN = OFF // Clock Switch Enable bit (The NOSC and NDIV bits cannot be changed by user software)
#pragma config FCMEN = ON // Fail-Safe Clock Monitor Enable bit (Fail-Safe Clock Monitor enabled)
#pragma config MCLRE = EXTMCLR // MCLR Enable bit (If LVP = 0, MCLR pin is MCLR; If LVP = 1, RE3 pin function is MCLR )
#pragma config PWRTS = PWRT_OFF // Power-up timer selection bits (PWRT is disabled)
#pragma config MVECEN = OFF // Multi-vector enable bit (Interrupt contoller does not use vector table to prioritze interrupts)
#pragma config IVT1WAY = OFF // IVTLOCK bit One-way set enable bit (IVTLOCK bit can be cleared and set repeatedly)
#pragma config LPBOREN = OFF // Low Power BOR Enable bit (ULPBOR disabled)
#pragma config BOREN = OFF // Brown-out Reset Enable bits (Brown-out Reset disabled)
#pragma config BORV = VBOR_2P45 // Brown-out Reset Voltage Selection bits (Brown-out Reset Voltage (VBOR) set to 2.45V)
#pragma config ZCD = OFF // ZCD Disable bit (ZCD disabled. ZCD can be enabled by setting the ZCDSEN bit of ZCDCON)
#pragma config PPS1WAY = ON // PPSLOCK bit One-Way Set Enable bit (PPSLOCK bit can be cleared and set only once; PPS registers remain locked after one clear/set cycle)
#pragma config STVREN = ON // Stack Full/Underflow Reset Enable bit (Stack full/underflow will cause Reset)
#pragma config DEBUG = OFF // Debugger Enable bit (Background debugger disabled)
#pragma config XINST = OFF // Extended Instruction Set Enable bit (Extended Instruction Set and Indexed Addressing Mode disabled)
#pragma config WDTCPS = WDTCPS_31// WDT Period selection bits (Divider ratio 1:65536; software control of WDTPS)
#pragma config WDTE = OFF // WDT operating mode (WDT Disabled; SWDTEN is ignored)
#pragma config WDTCWS = WDTCWS_7// WDT Window Select bits (window always open (100%); software control; keyed access not required)
#pragma config WDTCCS = SC // WDT input clock selector (Software Control)
#pragma config BBSIZE = BBSIZE_512// Boot Block Size selection bits (Boot Block size is 512 words)
#pragma config BBEN = OFF // Boot Block enable bit (Boot block disabled)
#pragma config SAFEN = OFF // Storage Area Flash enable bit (SAF disabled)
#pragma config WRTAPP = OFF // Application Block write protection bit (Application Block not write protected)
#pragma config WRTB = OFF // Configuration Register Write Protection bit (Configuration registers (300000-30000Bh) not write-protected)
#pragma config WRTC = OFF // Boot Block Write Protection bit (Boot Block (000000-0007FFh) not write-protected)
#pragma config WRTD = OFF // Data EEPROM Write Protection bit (Data EEPROM not write-protected)
#pragma config WRTSAF = OFF // SAF Write protection bit (SAF not Write Protected)
#pragma config LVP = OFF // Low Voltage Programming Enable bit (HV on MCLR/VPP must be used for programming)
#pragma config CP = OFF // PFM and Data EEPROM Code Protection bit (PFM and Data EEPROM code protection disabled)
// #pragma config statements should precede project file includes.

#include <xc.h>
#define _XTAL_FREQ 64000000

void __interrupt() RX (void);

unsigned char data=0;

void main(void) {
    ANSELA=0;
    ANSELC=0;
    TRISA=0;
    LATA=0;
    LATAbits.LA0=0; //hook
    LATAbits.LA4=0; //hook
    LATAbits.LA5=0; //hook
//UART init
    U1ERRIE=0;
    U1RXPPS=0b00010111; // PPS
    RC6PPS=0b00010011; // PPS
   
    U1CON0=0b00110000;
    U1BRGH=1; // BAUD 9600
    U1BRGL=159; // BAUD 9600
    U1CON1bits.ON=1;
    INTCON0bits.GIE=1;
    INTCON0bits.IPEN=0; // NO priorities
    PIE3bits.U1TXIE=1; // enable TX interrupt
    PIE3bits.U1RXIE=1; // enable RX interrupt
//UART init
    __delay_ms(100);
   
    while(1){
        LATAbits.LA0=0;
        __delay_ms(100);
        LATAbits.LA0=1;
        __delay_ms(100);
    } //while
}

void __interrupt() RX (void){
    if(PIR3bits.U1RXIF) {
        data=U1RXB;
        LATAbits.LA5=LATAbits.LA5^1;
    }
    LATAbits.LA4=LATAbits.LA4^1;
}

I only activated General, RX and TX interrupt, yet is triggering like madness, even try to insert this to see if any difference (even if I know some PIRbits are read only)

Code: Select all
PIE0=0; // desperation
PIE1=0; // desperation
PIE2=0; // desperation
PIE3=0; // desperation
PIE4=0; // desperation
PIE5=0; // desperation
PIE6=0; // desperation
PIE7=0; // desperation
PIE8=0; // desperation
PIE9=0; // desperation
PIE10=0; // desperation

PIR0=0; // desperation
PIR1=0; // desperation
PIR2=0; // desperation
PIR3=0; // desperation
PIR4=0; // desperation
PIR5=0; // desperation
PIR6=0; // desperation
PIR7=0; // desperation
PIR8=0; // desperation
PIR9=0; // desperation
PIR10=0; // desperation


Nope... still triggers the same. I think maybe I need to set or unset something in INCONx or maybe U1ERRIE some bit, or is not even related to UART... I don't know anymore. Anyone have any idea or see something I don't see at the moment.
https://www.tme.eu/Document/475e508ddf619bca87f4a27ea9509268/PIC18F47K42.pdf
32768hertz
 
Posts: 4
Joined: Fri Jan 03, 2020 5:39 pm

Re: 18F47K42 UART interrupt keep on triggering

Postby ric » Fri Jan 03, 2020 11:57 pm

Not your problem, but
#include <pic18f47k42.h>
should be just
#include <xc.h>
Do NOT include the device specific file yourself.

I only activated General, RX and TX interrupt, yet is triggering like madness, even try to insert this to see if any difference (even if I know some PIRbits are read only)

Do NOT enable the TX interrupt until you have something ready to send. It will interrupt whenever the TX register is ready to send something, which is all of the time except when it's busy.
You will find that almost all applications are actually easier to code WITHOUT using TX interrupts. Use interrupts for RX, but just polling code for the TX function.
I have used them, but only when I was using two USARTs transmitting simultaneously on another PIC device.
Latest test project, an LED matrix display made from one reel of addressable LEDs. here
User avatar
ric
Verified identity
 
Posts: 530
Joined: Sat May 24, 2014 2:35 pm
Location: Melbourne, Australia
PIC experience: Professional 5+ years with MCHP products

Re: 18F47K42 UART interrupt keep on triggering

Postby 32768hertz » Sat Jan 04, 2020 12:09 am

You where absolutely right, now is working fine. Thank you very much
I also removed #include <pic18f47k42.h> too
32768hertz
 
Posts: 4
Joined: Fri Jan 03, 2020 5:39 pm

Re: 18F47K42 UART interrupt keep on triggering

Postby ric » Sat Jan 04, 2020 12:17 am

n.b. one very convenient "trick" that is mentioned in the XC8 User Guide, but often missed by newcomers, is that you can define your own putch() function.
Code: Select all
void putch(char inchar)
{
    while (TXIF == 0);    // wait until TXBUF is free
    TXBUF = inchar;
}

Add this to your code, and you can now use printf() for output. :)
(You will need to #include <stdio.h> to get the function prototype for printf() )


It's documented under "3.5.8 How Do I Use Printf to Send Text to a Peripheral?" in the v1.xx User Guide, and
"2.5.8 How Do I Use Printf to Send Text to a Peripheral?" in the v2.xx User Guide.
Latest test project, an LED matrix display made from one reel of addressable LEDs. here
User avatar
ric
Verified identity
 
Posts: 530
Joined: Sat May 24, 2014 2:35 pm
Location: Melbourne, Australia
PIC experience: Professional 5+ years with MCHP products

Re: 18F47K42 UART interrupt keep on triggering

Postby 32768hertz » Sat Jan 04, 2020 12:56 am

What you are saying give me solution for another thing I was thinking. My RX problem was be for this, loud video:
https://www.youtube.com/watch?v=fFtj7zBLdK8
is an old daisy wheel Olivetti printer that I'm trying to resurrect for no reason at all. Video is more then a week old, now my printer is almost done
32768hertz
 
Posts: 4
Joined: Fri Jan 03, 2020 5:39 pm

Re: 18F47K42 UART interrupt keep on triggering

Postby ric » Sat Jan 04, 2020 1:02 am

Good luck.
Driving big mechanical devices from a PIC is fun.
Latest test project, an LED matrix display made from one reel of addressable LEDs. here
User avatar
ric
Verified identity
 
Posts: 530
Joined: Sat May 24, 2014 2:35 pm
Location: Melbourne, Australia
PIC experience: Professional 5+ years with MCHP products

Re: 18F47K42 UART interrupt keep on triggering

Postby AussieSusan » Mon Jan 06, 2020 3:09 am

Hopefully not too late but NEVER set the DEBUG config item - the IDE will do that for you depending on whether you do a 'release' or 'debug' build.
By setting it yourself, you may get unexpected results.
Susan
AussieSusan
Verified identity
 
Posts: 115
Joined: Mon Jun 16, 2014 4:45 am
PIC experience: Experienced Hobbyist

Re: 18F47K42 UART interrupt keep on triggering

Postby 32768hertz » Mon Jan 06, 2020 4:50 am

I did not known that, 18F47K42 is new to me, until now I only worked with 12F683 and 16F1829. For this, I set only the things I knew and the rest of them I leave them alone as the configuration bits set them by default.
32768hertz
 
Posts: 4
Joined: Fri Jan 03, 2020 5:39 pm

Re: 18F47K42 UART interrupt keep on triggering

Postby ric » Mon Jan 06, 2020 4:56 am

In reality, the Microchip tools seem to always ignore the DEBUG setting, as it is over-ridden by the mode the programmer is being used in.
(This is true for all PIC devices, not just the PIC18)
Still, just leave the DEBUG setting out altogether, as having it there gives the false impression that you CAN set it.
Latest test project, an LED matrix display made from one reel of addressable LEDs. here
User avatar
ric
Verified identity
 
Posts: 530
Joined: Sat May 24, 2014 2:35 pm
Location: Melbourne, Australia
PIC experience: Professional 5+ years with MCHP products


Return to SCI/USART/EUSART

Who is online

Users browsing this forum: No registered users and 2 guests