PIC16F17145 USART2 not working

[mmotte]

I have been here before (https://sourceforge.net/p/gcbasic/discussion/579125/thread/5c6e3334fa/)

I follow the forum and I was going to help a guy with CH376 module. I needed to put a protoboard together, which I have done BUT it don't work on the USART 2 port. I have spent parts of a few days on this. I have tried two known good ttl to USB converters and it's not that. PPS program does Not have RX1 and RX2 in but they are default and I have programmed around pps anyhow just to try. Then I remebered WE did this before. I looked that stuff up and looked at the usart.h file ( you have been digging around in there again! a SELECT oh my!). I can't find the problem yet. We had this working before.

I will continue to work on this but 4 eyes are better than 2 .

Attached is a cluttered up test file. Usart 1 works. Usart 2 neither receives not transmits.

Thanks
Mike O w9ys

[Anobium]

What build of the compiler you on? This was fixed in 10/08/2024 builds.

[mmotte]

2025.10.04 (Windows 64 bit) : Build 1523

wINDOWS 7

[Anobium]

Oh...

I better have a look then!

[Anobium]

I need clarity.

Forget PPS for a moment, what is needed? PORTc.0 cannot do two things. So, what is the desired port assignment?

  Dir PORTc.0 Out        'second USART Tx Pin
  Dir PORTc.2 In         'second USART Rx Pin
  Dir PORTc.0 Out        'First USART Tx Pin
  Dir PORTB.5 In 

[Anobium]

Does this work? Sends a message on USART1 and USART2. If this works then we have the PPS corrected.

Evan

#chip 16F17145, 8

#option explicit


#startup InitPPS, 85
    #define PPSToolPart 16F17145

    Sub InitPPS
    UNLOCKPPS

            RC2PPS = 0x16;  //RC2->EUSART2:TX2;
            RC0PPS = 0x13;  //RC0->EUSART1:TX1;

            RX2PPS = 0x11; //RC1->EUSART2:RX2;
            RX1PPS = 0x0D; //RB5->EUSART1:RX1;


    LOCKPPS
    End Sub
    // Add this code segment to your GCBASIC source program

// Define USART control constants.
  #DEFINE SCRIPT_USART_USAGE_CHECK

  #define USART2_BAUD_RATE 9600
  #define USART2_DELAY off
  #define USART2_TX_BLOCKING

  #define USART_BAUD_RATE 9600
  #define USART_DELAY off
  #define USART_TX_BLOCKING

  Dim tempvalue as Byte

wait 5 s

HSerPrintStringCRLF "USART1", 1
HSerPrintStringCRLF "USART1", 2

wait 100 ms

[mmotte]

Slight edit on your test2 program "USART2", 2

But it prints USART1 out of the USART 2 Port and nothing comes out of the USART1 port.

Don'r we need the "Dir" statements??

This is what I want:
RB5 is RX1
RC2 is TX1

RC1 is RX2
RC0 is TX2

That is what is in the PPS!

[mmotte]

I added the "DIR" statement and it made no difference

Prints USART1 out of the USART2 port Pin RC0

[mmotte]

PPS messed up??

I have to go and pickup my wife. Be gone for a bit.

[mmotte]

I have done some experimenting. I have chosen 2 other pins for TX2 output 16. No output

I chose DT2 output 18 and it send a bunch of 0's. so the pin is functional.

USART 1 continues to function.

So UART2 is NOT putting out anything which points back to programming or setup of USART2??

M

[mmotte]

The the .asm file

  banksel TX1REG
  movwf TX1REG
HSERSENDUSART2HANDLER
  goto  SysSelectEnd1
SysSelect1Case2
  movlw 2
  subwf COMPORT,W

Line 208 goto SysSelectEnd1 ,looks like it prevents getting to the 2cd USART.

[mmotte]

In the above assembly, I just realized that it don't have to go through line 208. Comport is 2 when HSERSEND345 routine is called and then the SELECT sends you to "SysSelect1Case2" , so it should work!

Iam at a loss for the how this piece of code in USART.H works though.

          #ifdef Var(TXREG2)
             //~WRITE THE DATA BYTE TO THE USART
             //~ Sets register to value of SerData - where register could be TX2REG, TXREG2  or U2TXB  via the #samevar
             #IFDEF VAR(TX2REG)
              TX2REG = SerData
             #ELSE
              TXREG2 = SerData
            #ENDIF

How do we get inside the outer #ifdef Var(TXREG2)? When we have a TX2REG?
I tried commenting it out but that did not work. AND it actually shows up correctly in the .asm file, so it must have worked.
I know, maybe my mind is getting too old for coding! No , it isn't. I love digging around in this.

I need help yet. What do I test next?

BR
Mike

[mmotte]

Just checking RC0 again.

 Sub InitPPS
    UNLOCKPPS

            RC2PPS = 0x16;  //RC2->EUSART2:TX1; swapped
            RC0PPS = 0x13;  //RC0->EUSART1:TX2;

So I swapped the 0x13 and 0x16.
Now the "USART1" message comes out of Port RC0 instead of RC2.
No action on RC2.

I am swapping them back.

[Anobium]

Do check your PPS.

But, then update with the library attached. The setting of the baudrate was creating byte vars rather updating the registers. This should work.

[mmotte]

Thank You Anobium!! It works!

How did you find it? Where did you look?

BR
Mike

[Anobium]

You ask the killer question and AI would do this. ( well AI will once I type it up here! ).

To find the root cause of any issues I always look at the ASM.
Start in the variable definition area. Look for variables that actually look like registers. This takes experience to spot them but the next step will highlight them anyway. I spotted SPBRG2, SPBRGH2. As I am using GCCode they are displayed in a different color as the GCCode error handler is helping here. But, let us assume for a moment the you do not spot this.
Then, add to the top of USART.H, we know it this library #OPTION EXPLICIT
Recompile. You will see the source file location.
So, we have the source location of some registers and we have the register name.
Well, a search in PICINFO quickly showed me the target registers did not exist. But, in this chipfamily there is a register with the same functionality.
So, to resolve we use #samevar. And, the compiler has map from one register name to the other. So, no functional changes the code just the #samevar.

#samevar SPBRG2, SP2BRG
#samevar SPBRGH2, SP2BRGH 

---

Background

Microchip has a naming convention for registers and register bits, but it was established without much long‑term planning. Because there is very little change control, the same register function often ends up with multiple—though somewhat similar—names.

To manage this, we introduced #samevar and #samebit many years ago to reduce duplication within the library code. The library contains a significant amount of built‑in logic, and to fully understand how it generates the final assembly output, you need to view the GCBASIC alongside the produced ASM.

Hope this provides some clarity.