• AVR Freaks

Hot!PIC16F690 EUSART TXIF flag simulation problem

Author
bologrew
New Member
  • Total Posts : 6
  • Reward points : 0
  • Joined: 2020/02/14 11:49:04
  • Location: 0
  • Status: offline
2020/02/19 05:11:10 (permalink)
0

PIC16F690 EUSART TXIF flag simulation problem

20MHz PIC16F690
MPLAB X IDE version 5.30
MPASM version 5.86
PIC16Fxxx_DFP version 1.1.23


Greetings.
I am working on a 20MHz PIC16F690 half-duplex 9600bps RS485 project and have run into a problem when running the code in the simulator.  My project uses interrupt driven communications but I have replicated the problem with simple polling as shown in the attached file.
Put simply, I can send bytes to the TXREG register forever without the TXIF bit in PIR1 ever changing.  This makes the interrupt re-trigger immediately on return from interrupt.
 
The attached program demonstrates  the same problem as it gets stuck in an infinite loop.
If I add PIR1 and TXSTA to the "Variables" window, I can manually alter the TXIF and TRMT bits to change the program behaviour even though those bits are read-only and I shouldn't be able to change them.  My real project monitors the TRMT bit of the TXSTA register to ensure that all the data has been transmitted before switching the RS485 chip from transmit to receive.  The TRMT  bit doesn't change as bytes are fed into TXREG or transmitted out either.
I have run the same code through the open source "gpsim" and it behaves as expected with a roughly 1 millisecond delay between TXIF going from zero to one.
 
I hope you can help me.  I'm happy to test any modified DFP that you might produce.
 
Best regards,
Nicholas Redgrave
#1

13 Replies Related Threads

    GeorgePauley
    Moderator
    • Total Posts : 1220
    • Reward points : 0
    • Joined: 2009/12/01 13:59:30
    • Location: Chandler AZ
    • Status: offline
    Re: PIC16F690 EUSART TXIF flag simulation problem 2020/02/19 11:38:29 (permalink)
    0
    I find this bit of code interesting...
     

    TLOOP
    ;
      movwf  TXREG          ;transmit it
      nop
      nop                   ;TXSTA,TRMT should also change to 0 (TSR full)
      nop
      btfsc  PIR1,TXIF      ;is TXIF flag clear(buffer full) (two bytes should clear it)
      goto   TLOOP          ;not full, send more bytes
    ;
      nop                   ;should reach here after two bytes but loops forever
                            ;if interrupts are used to transmit, it will never stop interrupting

     
    The TXIF flag is set when we enter TLOOP for the first time.  To be clear, the device (simulator in this case) will set the TXIF flag when the transmission occurs.  It is up to the user to clear this flag (presumably in an interrupt service routine).  Since no code actually clears TXIF, we get stuck in this loop forever.
    #2
    GeorgePauley
    Moderator
    • Total Posts : 1220
    • Reward points : 0
    • Joined: 2009/12/01 13:59:30
    • Location: Chandler AZ
    • Status: offline
    Re: PIC16F690 EUSART TXIF flag simulation problem 2020/02/19 11:40:42 (permalink)
    +2 (2)
    How have I never heard of gpsim?!  I have reached out to Scott Datallo (the original author) and am looking forward to some engineering discussions with him.
    #3
    ric
    Super Member
    • Total Posts : 26091
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: PIC16F690 EUSART TXIF flag simulation problem 2020/02/19 12:27:49 (permalink)
    0
    GeorgePauley
    ...
    The TXIF flag is set when we enter TLOOP for the first time.  To be clear, the device (simulator in this case) will set the TXIF flag when the transmission occurs.  It is up to the user to clear this flag (presumably in an interrupt service routine).  Since no code actually clears TXIF, we get stuck in this loop forever.

    Huh?
    TXIF is set in hardware whenever TXREG is empty.
    The first write to TXREG will immmediately shift to the TSR, so TXIF will be re-set almost instantly.
    The second write to TXREG should cause TXIF to go low until the TSR is ready for this second data byte.
     
    As the OP stated, this flag is read-only, the ONLY way you can clear it in code is to write data to TXREG, and it will only stay low while the TSR is busy transferring the previous value.
     
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #4
    bologrew
    New Member
    • Total Posts : 6
    • Reward points : 0
    • Joined: 2020/02/14 11:49:04
    • Location: 0
    • Status: offline
    Re: PIC16F690 EUSART TXIF flag simulation problem 2020/02/19 13:18:19 (permalink)
    0
    Thank-you for your reply.
    I find this interesting, you say:
    "To be clear, the device (simulator in this case) will set the TXIF flag when the transmission occurs.  It is up to the user to clear this flag"
    According to my data sheet, in PIR1 the TXIF flag is marked as read-only.  It says the only way to change its value is to write to TXREG.  Hence initially writing to TXREG twice clears this flag as the first byte is transferred to the TSR register.
     
    Quoting from the EUSART 12.1.1.3 section, "In other words, the TXIF bit is only clear when the TSR is busy with a character and a new character has been queued for transmission in the TXREG. The TXIF flag bit is not cleared immediately upon writing TXREG. TXIF becomes valid in the second instruction cycle following the write execution. Polling TXIF immediately following the TXREG write will return invalid results. The TXIF bit is read-only, it cannot be set or cleared by software.
    The TXIF interrupt can be enabled by setting the TXIE interrupt enable bit of the PIE1 register. However, the TXIF flag bit will be set whenever the TXREG is empty, regardless of the state of TXIE enable bit."

    The TRMT bit in TXSTA is also read-only.
    I used a purely polled transmit scheme on a previous project using the PIC16F690 which looked like this:
     
    ; Transmit the data
    ;
    TLOOP1
    ;
      movf    INDF,W        ;read byte for transmission
      movwf   TXREG         ;send to serial port
      incf    FSR,F         ;increment pointer to next byte in transmit buffer
    ;
    TLOOP2
    ;
      nop                   ;TXIF not valid yet so wait
      btfss   PIR1,TXIF     ;has the byte been sent yet?
      goto    TLOOP2        ;no, loop until sent
    ;
      decfsz  TXBYTES,F     ;decrement loop counter, is it zero?
      goto    TLOOP1        ;no, send next byte


    This scheme clearly works as I embedded the PIC hardware in my CNC controller box.
     
     
    Regarding "gpsim", I have been using it for years and only recently started using the MPLAB IDE when I wanted to use the PIC16F18313 which "gpasm" could build code for but "gpsim" could not debug.
     
    I look forward to your reply.
    Best regards,
    Nicholas Redgrave
     
    #5
    GeorgePauley
    Moderator
    • Total Posts : 1220
    • Reward points : 0
    • Joined: 2009/12/01 13:59:30
    • Location: Chandler AZ
    • Status: offline
    Re: PIC16F690 EUSART TXIF flag simulation problem 2020/02/19 15:33:44 (permalink)
    +1 (1)
    You guys are correct.  TXIF and RXIF are read only, and cleared by the hardware.  I strongly suspect the simulator doesn't work this way.  When I debugged this (very old simulator code that I didn't write wink: wink) I assumed TXIF and RXIF worked like every other IF flag in the system.  So it looked like everything was working as expected.  Let me re-examine with my new knowledge.  Hopefully sometime tomorrow.
    #6
    GeorgePauley
    Moderator
    • Total Posts : 1220
    • Reward points : 0
    • Joined: 2009/12/01 13:59:30
    • Location: Chandler AZ
    • Status: offline
    Re: PIC16F690 EUSART TXIF flag simulation problem 2020/02/20 16:19:39 (permalink)
    +1 (1)
    I believe the problem is that you're baud rate is very fast.

    I started with my own test, which worked fine.
     

    #include <xc.h>

    void main(void)
        {
        RCSTAbits.SPEN = 1;
        TXSTAbits.TXEN = 1;
        TXREG = 0x30;
        while (PIR1bits.TXIF != 1);
        TXREG = 0x31;
        while (PIR1bits.TXIF != 1);
        TXREG = 0x32;
        while (PIR1bits.TXIF != 1);
        TXREG = 0x33;
        while (PIR1bits.TXIF != 1);
        TXREG = 0x34;
        while (1);
        }

     
    Which begged the question, why doesn't your routine work?  First realization was that I forgot to turn on UART output to window for your project.  After I did that I noticed that your routine is transmitting 'A' characters.  So it IS working.

    A little more investigation and I realized that your routine is transmitting instantaneously.  The simulator believes that it takes 0 instruction cycles to transmit chars in your routine.  So the TXIF flag has already been reset to 1 by the time you get around to making the check.
     

    TLOOP
    ;
      movwf  TXREG          ;transmit it
      nop
      nop                   ;TXSTA,TRMT should also change to 0 (TSR full)
      nop
      btfsc  PIR1,TXIF      ;is TXIF flag clear(buffer full) (two bytes should clear it)
      goto   TLOOP          ;not full, send more bytes
    ;
      nop                   ;should reach here after two bytes but loops forever
                            ;if interrupts are used to transmit, it will never stop interrupting


    Now I'm highly suspicious of the simulator's baud rate calculation, primarily since it does not seem to reference the Fosc property from the project properties page.  How in the heck can we know how many instructions to wait between transmissions if we don't know Fosc?  But I've been wrong in my analysis of this complex code before, and might be again.  So I have some more research to do.

    But, I believe this means you can modify your code slightly and be able to proceed.  You're never going to get out of the loop because TXIF is always 1.  So modify the loop test condition accordingly.

    You may also want to double check your baud rate generator values?
    #7
    bologrew
    New Member
    • Total Posts : 6
    • Reward points : 0
    • Joined: 2020/02/14 11:49:04
    • Location: 0
    • Status: offline
    Re: PIC16F690 EUSART TXIF flag simulation problem 2020/02/20 18:34:31 (permalink)
    0
    Thank-you for your investigation.
     

    "I believe the problem is that your baud rate is very fast."

    Well yes it is effectively running very fast but it shouldn't be with the values I've used.  It's only set to 9600 bps although there is provision to run it as fast as 38400 in my code.  The datasheet explicitly quotes speeds up to 115.2k bps so I'm hardly taxing it.
    I know that the baud rate is set correctly because I am also flashing this code to a real PIC16F690 with a 20MHz crystal hooked up on a breadboard to an LTC485 chip which is talking via a USB->RS485 adapter to terminal software.  The real life transmission of bytes is occurring correctly with no errors since my data is also checksummed.
     
    This made me wonder if I had set the simulation instruction speed wrong but I checked and it is set to 5MHz (20MHz divided by four clock cycles per instruction).
    To further check that the simulator has the correct  clock speed I used the stopwatch function to time a 50ms delay subroutine in the program which relies on having the correct  instruction speed.  The stopwatch said 50.001 ms so the simulator has correctly picked up the instruction speed.
     

     
    T1DELAY50
    ;
    ; Initialise Timer 1
    ; T1GINV="0"  TMR1GE="0"  T1CKPS1="1"  T1CKPS0="1" Prescaler 1:8="11"
    ; T1OSCEN="0"  T1SYNC="0"  TMR1CS="0" internal clock  TMR1ON="0" off
    ; 00110000 = 48
    ;
    ; Delay is (65536-count) * prescaler/5,000,000 in seconds
    ; e.g. 65536-34286 = 31250 * 8/5,000,000 = 50.0ms
    ;
      movlw   48
      movwf   T1CON         ;set it
      bcf     PIR1,TMR1IF   ;clear Timer 1 overflow flag
      movlw   133
      movwf   TMR1H
      movlw   238
      movwf   TMR1L
    ;
      bsf     T1CON,TMR1ON  ;activate Timer 1
    ;
    TIMER50LOOP
    ;
      btfss   PIR1,TMR1IF   ;has the timer overflowed?
      goto    TIMER50LOOP   ;no, loop
    ;
      bcf     T1CON,TMR1ON  ;deactivate Timer 1
      bcf     PIR1,TMR1IF   ;clear Timer 1 overflow flag
      return                ;return from subroutine
    ;

     
     

    "After I did that I noticed that your routine is transmitting 'A' characters.  So it IS working.
    A little more investigation and I realized that your routine is transmitting instantaneously.  The simulator believes that it takes 0 instruction cycles to transmit chars in your routine.  So the TXIF flag has already been reset to 1 by the time you get around to making the check."

     
    Yes, this is exactly the behaviour I am seeing.  It's like the simulated baud rate is 50,000,000 bps (10 bits in one instruction cycle) rather than 9600 bps.  Once the TSR and TXREG are both filled, it should take ~1 ms to empty the TSR and the byte in TXREG to get transferred to the TSR before the TXIF flag changes again.
     
     

    "Now I'm highly suspicious of the simulator's baud rate calculation, primarily since it does not seem to reference the Fosc property from the project properties page.  How in the heck can we know how many instructions to wait between transmissions if we don't know Fosc?"

     
    Indeed.  The baud rate calculation (section 12.3 of the datasheet) explicitly requires Fosc and the later example tables list the values for the baud rate registers to get desired baud rates for various different values of Fosc.
     
    "But, I believe this means you can modify your code slightly and be able to proceed.  You're never going to get out of the loop because TXIF is always 1.  So modify the loop test condition accordingly."
     
    My actual code is interrupt driven and my data packets are typically eight bytes long.  The simulation does output the packet and when there are no more bytes to be sent, it disables the interrupt.  It's just that as soon as it leaves the ISR, it immediately re-interrupts so all eight bytes get sent without a single instruction getting executed in the non-isr code when it should take more like 8 ms or something like 40,000 instructions.
    However, the code also checks the TRMT flag of the TXSTA register to make sure the data has really been clocked out before switching the RS485 chip from transmit to receive.  I'm guessing TRMT has the same problem as TXREG with the data being instantly clocked out rather than at the programmed baud rate.
    I will have to IFDEF that code out for simulation purposes.

    "You may also want to double check your baud rate generator values?"
    They are correctly set and work in real life.
    I have tried simulating my example code with a PIC16F882 as well and it has the exact same problem which isn't surprising since it uses the same DFP.
     
    Best regards,
    Nicholas Redgrave
    #8
    GeorgePauley
    Moderator
    • Total Posts : 1220
    • Reward points : 0
    • Joined: 2009/12/01 13:59:30
    • Location: Chandler AZ
    • Status: offline
    Re: PIC16F690 EUSART TXIF flag simulation problem 2020/03/03 15:47:36 (permalink)
    0
    Problem is fixed in 5.40.
     
    The ultimate issue was that 16F690 decided to rename BAUDCON register to BAUDCTL.  Simulator was looking for BAUDCON, didn't find it, and assumed it was a flavor of UART that didn't have BAUDCON.  Even worse that flavor of UART also doesn't have a SPBRGH register either.  So baud rate was doomed.
     
    If you need it, I (think I) can give you a tricky edit to make to one of the MPLAB X jar files that will correct the problem for you.
    #9
    bologrew
    New Member
    • Total Posts : 6
    • Reward points : 0
    • Joined: 2020/02/14 11:49:04
    • Location: 0
    • Status: offline
    Re: PIC16F690 EUSART TXIF flag simulation problem 2020/03/03 17:49:54 (permalink)
    0
    Excellent!
     
    Yes, if you tell me what to do, I will try to do the jar file edit.  Alternatively, if you have somewhere I can download the new jar file from, that would be good too.  Whatever works for you.
     
    Many thanks for your efforts.
     
    Best regards.
     
    #10
    GeorgePauley
    Moderator
    • Total Posts : 1220
    • Reward points : 0
    • Joined: 2009/12/01 13:59:30
    • Location: Chandler AZ
    • Status: offline
    Re: PIC16F690 EUSART TXIF flag simulation problem 2020/03/13 10:40:09 (permalink)
    +1 (1)
    bologrew, have you ever received a message from me about how to fix simulator?  I've sent two, but when I check my sent box, they don't show up.
    #11
    bologrew
    New Member
    • Total Posts : 6
    • Reward points : 0
    • Joined: 2020/02/14 11:49:04
    • Location: 0
    • Status: offline
    Re: PIC16F690 EUSART TXIF flag simulation problem 2020/03/13 14:02:35 (permalink)
    0
    Sorry, no I haven't received any messages from you except for a notification email from this board telling me there is a reply to this thread.  I have checked my email provider and no messages have been accidentally flagged as spam either.
    Can you post the instructions in this thread?
    I guess you're very busy and haven't got to the "PIC16F690 EUSART Receive"  thread yet.  Has your repair fixed the receive side of things too?
     
    Best regards,
    Nicholas Redgrave
    #12
    ric
    Super Member
    • Total Posts : 26091
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: PIC16F690 EUSART TXIF flag simulation problem 2020/03/13 14:33:30 (permalink)
    +1 (1)
    Have you tried just looking in your forum inbox?
    Go via the "PMs" button in the menu.
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #13
    dan1138
    Super Member
    • Total Posts : 3389
    • Reward points : 0
    • Joined: 2007/02/21 23:04:16
    • Location: 0
    • Status: offline
    Re: PIC16F690 EUSART TXIF flag simulation problem 2020/03/13 14:41:35 (permalink)
    +2 (2)
    GeorgePauley
    bologrew, have you ever received a message from me about how to fix simulator?  I've sent two, but when I check my sent box, they don't show up.



    Do you think the forum software is helping with this? :(
    #14
    Jump to:
    © 2020 APG vNext Commercial Version 4.5