CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Disable UART1 & UART2 and PMD5 register

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
soonc



Joined: 03 Dec 2013
Posts: 215

View user's profile Send private message

Disable UART1 & UART2 and PMD5 register
PostPosted: Tue Jun 16, 2020 3:13 pm     Reply with quote

Using Latest Compiler V5.093
Chip: PIC18F47K42

The code starts NOT using UART1 or UART2.

Code:

#pin_select U2TX = PIN_B0
#pin_select U2RX = PIN_B1
#use rs232 ( baud=9600, parity=N, xmit=PIN_B0, rcv=PIN_B1, bits=8, stream=CM2, NOINIT, errors )

#pin_select U1TX = PIN_C6
#pin_select U1RX = PIN_C7
#use rs232(baud=115200, parity=N, xmit=PIN_C6, rcv=PIN_C7, bits=8, stream=CM1, NOINIT, errors )


Measuring PIN_B0 and B1 also PIN_C6 and C7 all four are 0V this is what I need.

Using setup_uart(115200,CM1); Com port 1 will only work if I declare
#use fast_io(c) // that's another issue.

Now I want to Disable CM1 so I use this statement:

setup_uart(false,CM1);

and PIN_C6 remains High (about 3.3V) and PIN_C7 is low but what I really want is PIN_C6 to be low also just like when the code started.

With PIN_C6 high there is a current drain into the dead module which is what I don't need.

I tried output_low(PIN_C6) does nothing.

So I looked at the .lst file for assembly code.

Code:

....................   setup_uart(false,BLE);
03362:  MOVLB  3D
03364:  BCF    xF3.7
03366:  BCF    xF2.4
03368:  BCF    xF2.5


If I am correct the example is clearing bits 7,4,5 at address 0X3DF3 and 0X3DF2 which should disable the Uart1 but the Rx line is still high.

I tried using the PMD5 register to disable the two UART modules but PIN_C6 still remains high.

Code:

#word PMD5_ = 0X39C5
#bit  U2MD = PMD5_.5
#bit  U1MD = PMD5_.4

            U2MD = 0;
0335C:  MOVLB  39
0335E:  BCF    xC5.5
            U1MD = 0;
03360:  BCF    xC5.4

PIN_C6 still remains high.

What do I need to do to get PIN_C6 low so as to stop the current draining into a dead module ?

As usual I suspect I'm doing something wrong.
dluu13



Joined: 28 Sep 2018
Posts: 395
Location: Toronto, ON

View user's profile Send private message Visit poster's website

PostPosted: Tue Jun 16, 2020 4:14 pm     Reply with quote

I'm not sure if this will work but there's a built in function called pin_select() and you could set U1TX and U1RX to null. Maybe you need to totally unmap the pins from the UART. On the road so I can't test it right now :p
jeremiah



Joined: 20 Jul 2010
Posts: 1314

View user's profile Send private message

PostPosted: Tue Jun 16, 2020 6:44 pm     Reply with quote

Have you verified that you are actually using hardware UARTs? Your #use rs232() calls are setup to be potentially software UARTS instead of hardware UARTS. For software UARTS you specify the pins (which is what you did) but for hardware UARTS you are supposed to specify the module.

Some versions of the compiler can still make a hardware UART out of the call you did, but not all.

try changing your #use RS232() calls to:

Code:

#use rs232 (UART2, baud=9600, parity=N, bits=8, stream=CM2, NOINIT, errors )


and

Code:

#use rs232(UART1, baud=115200, parity=N, bits=8, stream=CM1, NOINIT, errors )
soonc



Joined: 03 Dec 2013
Posts: 215

View user's profile Send private message

Thanks that fixed it
PostPosted: Tue Jun 16, 2020 6:58 pm     Reply with quote

dluu13 wrote:
I'm not sure if this will work but there's a built in function called pin_select() and you could set U1TX and U1RX to null. Maybe you need to totally unmap the pins from the UART. On the road so I can't test it right now :p


Good call..
I read the "Sticky" post about #Pin Select...

Thanks.
soonc



Joined: 03 Dec 2013
Posts: 215

View user's profile Send private message

Thanks
PostPosted: Tue Jun 16, 2020 7:01 pm     Reply with quote

jeremiah wrote:
Have you verified that you are actually using hardware UARTs? Your #use rs232() calls are setup to be potentially software UARTS instead of hardware UARTS. For software UARTS you specify the pins (which is what you did) but for hardware UARTS you are supposed to specify the module.

Some versions of the compiler can still make a hardware UART out of the call you did, but not all.

try changing your #use RS232() calls to:

Code:

#use rs232 (UART2, baud=9600, parity=N, bits=8, stream=CM2, NOINIT, errors )


and

Code:

#use rs232(UART1, baud=115200, parity=N, bits=8, stream=CM1, NOINIT, errors )


pin_select() fixed the I/O levels but you may have a point about the way I declared the #use RS232...

I'll check to see if that's why I have to use "#use fast_io(c) for the uart to work at all.

I removed the #use fast_io(c) and
Code:

#use rs232(UART1, baud=115200, stream=CM1, NOINIT, errors )


Uart works !

Thanks for the heads up.
jeremiah



Joined: 20 Jul 2010
Posts: 1314

View user's profile Send private message

PostPosted: Tue Jun 16, 2020 7:19 pm     Reply with quote

My general rule of thumb is that if I am finding myself using #use fast_io(), then I am probably doing something the hard way or wrong way 99% of the time. Even if I legit need to have the speed on the I/O, I usually find that #bit B1 = getenv("BIT:LATB12") or similar works better for me. I think the only time I have used #use fast_io() is for reading or writing an entire port fast (but even then I could use the #word PORTB = getenv("SFR:LATB") or similar).
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Wed Jun 17, 2020 2:55 am     Reply with quote

This is a data sheet one:
Quote:

(section 31.1)
When the TRIS control for the pin corresponding
to the TX output is cleared, then the UART will maintain
control and the logic level on the TX pin. Changing the
TXPOL bit in UxCON2 will immediately change the TX
pin logic level regardless of the value of EN or TXEN


Basically once the UART TX is connected to the pin, it overrides the
pin drive, even if the UART is disabled...

As Soonc says the 'answer' is to un-map the pins from the UART,
with pin_select. You can even leave the UART enabled. Just disconnect
the pins from it. Very Happy

See you have found this to work.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group