Menu

PIC 18F25K22 does not return from Rx interrupt

Miroslav
2021-02-26
2021-03-01
  • Miroslav

    Miroslav - 2021-02-26

    PIC 18F25K22 does not return from Rx interrupt. I tried this code on 18f4550,18f25k20 devices ... there is everything working properly. Is it possible that the problem is only with this device? The interrupt routine does not clear the rx interupt flag. Here is my test code. Thanks

     
  • Anobium

    Anobium - 2021-02-26

    I am not sure what this issue is. Could just be this chip. Can you load into MPLAB to isolate the issue?

    Try ( just to remove the function call) to use the subroutine() - may help/may not help.

    sub rx_int
    
       HSerReceive ( rxbyte )
       rxflag = 1 : led1 =! led1
    
    End sub
    
     
    • Anobium

      Anobium - 2021-02-26

      Oh, when you say the rx interupt flag did you mean rxflag (your variable) or did you mean RC1IF ?

      And, does the onterrupt routine does set the rxflag flag if you do not call HSerReceive function?

       
  • Miroslav

    Miroslav - 2021-02-26

    Do not clear RC1IF. if I use HSerReceive ( rxbyte ) will also remain in the interupt loop. if I do not call HSerReceive, rxflag is set (led1 "flash")

     
    • Anobium

      Anobium - 2021-02-26

      I looked at the asm. It should be clearing RC1IF. There is way for it not to be cleared.

      It is more likely to be another event happening.

      Can you put up in MpASM and debug?

       
  • Miroslav

    Miroslav - 2021-02-26

    I can not put up in MpASM and debug :( I tried test register PIR1.5 in interupt. Led1 "flash".

    sub rx_int
    if PIR1.5 = 1 then
    rxbyte = HSerReceive1
    rxflag = 1 : led1 =! led1
    end if
    End sub

     
  • Anobium

    Anobium - 2021-02-26

    The asm. (does your ASM look the same?)

    Can only call RX_INT if RC1IE and RC1IF are set to 1. And, after the rcall completes the RC1IF is cleared. So, at the moment, I think the RC1IF is being cleared.

    ;On Interrupt handlers
        btfss   PIE1,RC1IE,ACCESS
        bra NotRC1IF
        btfss   PIR1,RC1IF,ACCESS
        bra NotRC1IF
        rcall   RX_INT
        bcf PIR1,RC1IF,ACCESS
        bra INTERRUPTDONE
    
     
  • Miroslav

    Miroslav - 2021-02-26

    Here is my asm it's the same..

    ;On Interrupt handlers
    btfss PIE1,RC1IE,ACCESS
    bra NotRC1IF
    btfss PIR1,RC1IF,ACCESS
    bra NotRC1IF
    rcall RX_INT
    bcf PIR1,RC1IF,ACCESS
    bra INTERRUPTDONE

     
    • Anobium

      Anobium - 2021-02-26

      OK. I can look on Monday. .... check back then... if you have not resolved.

       
  • William Roth

    William Roth - 2021-02-27

    @Miroslav

    I put an 18F25K22 on a breadboard and loaded up the code. It works fine.

    LED flashes continually as expected .

    When a byte is received LED1 toggles as expected. This indicates that there was an interrupt.

    The code returns from the interrupt as indicated by LED continuing to flash after LED1 toggles. If the program was not returning from the interrupt, LED would stop flashing after the serial data was received.

    Suggest you check your wiring and connections. Check for a bent/folded pin on the chip.

    William

     
  • Anobium

    Anobium - 2021-02-27

    I am with Bill on this one. I cannot do any testing this weekend, but, the code should work.

    When I looked yesterday... I did think that Miroslav was lucky to even get the other chips working. The input buffer will be overrun by the wait 100 ms. The style of the code is not idea. Recommend using a serial buffer ring.

     
  • Miroslav

    Miroslav - 2021-02-27

    William can you try my hex? The connection is definitely right, I tried it on a board that works with a program compiled in Proton basic, it's a large project that I wanted to rewrite into GCbasic. I tried my code in ISIS simulator the result was the same. Interestingly, it works without problems on other processors.

     
  • William Roth

    William Roth - 2021-02-27

    Your hex file fails and is different from mine that was generated by Great Cow Basic (RC42).
    Was your hex generated from the exact same GCB file that you previously posted?

    We need to know what version of GCB you are using and how you are assembling the hex. Are you using the GCB assembler ( GCASM) or something else?.

    William

     
  • Jerry Messina

    Jerry Messina - 2021-02-28

    just fyi... RCxIF is a read-only bit. It gets cleared when the RCREGx is read.

     
  • William Roth

    William Roth - 2021-02-28

    @Miroslav

    You are using an older version the current release of Great Cow BASIC. There have been many updates to the USART library and compiler since. Please download and install the latest Release Candidate of Great Cow Basic.

    https://sourceforge.net/projects/gcbasic/files/Release%20Candidates/GCB_Installer-v0.98.07%20RC42.exe/download

    Once installed compile and test the exact same program that you posted.

    Remember that on 18F25K22 the RX Pin is on PORTC.7 (Pin 18)

     

    Last edit: William Roth 2021-02-28
  • William Roth

    William Roth - 2021-02-28

    I have confirmed that this problem is related to the Great Cow Basic USART Library. The problem exists in the Current Release Version ( 0.98.06 2019-06-12)

    Updating to RC42 in the link posted above will resolve.

     
  • Miroslav

    Miroslav - 2021-02-28

    Everything works. THANK YOU William.

     
  • Anobium

    Anobium - 2021-03-01

    @Miroslav - for you. A serial ring buffer solution. Your code will drop bytes. I essentially took the code from the Help and changed the chip.

    Enjoy

     

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.