USART2 Problem 67J94
Moderators: David Barker, Jerry Messina
-
- Posts: 22
- Joined: Thu Sep 05, 2013 4:45 pm
- Location: United Kingdom
USART2 Problem 67J94
I am currently having problems with a 67J94 and wondered if anyone else is using this device or family successfully?
The baud rates and pin directions are correct for both USARTS as I can measure this on an oscilloscope, and I can see characters
appearing on a terminal emulation program. N.B. I am currently only ever using one 'USART' include module in my program at a time.
The following code (excerpt) works perfectly and characters are output via USART1.
Public Sub Print(pStr as String)
USART.Write(pStr, 13, 10)
end sub
MyString = "Hello World"
While (true)
Print(Mystring)
Delayms(50)
Wend
However when using USART2 only the carriage return and line feed characters are output, which can be viewed on an oscilloscope,
and seen on the terminal emulation program.
Public Sub Print(pStr as String)
USART2.Write(pStr, 13, 10)
end sub
MyString = "Hello World"
While (true)
Print(Mystring)
Delayms(50)
Wend
The following statement works correclty to USART2 and all characters are output.
USART2.Write("H","e","l","l","o"," ","W","o","r","l","d",13,10)
Therefore it would appear that when passing a string argument to my print function directed to USART2 the character string is somehow lost / becomes null.
Any help would be gratefully received.
The baud rates and pin directions are correct for both USARTS as I can measure this on an oscilloscope, and I can see characters
appearing on a terminal emulation program. N.B. I am currently only ever using one 'USART' include module in my program at a time.
The following code (excerpt) works perfectly and characters are output via USART1.
Public Sub Print(pStr as String)
USART.Write(pStr, 13, 10)
end sub
MyString = "Hello World"
While (true)
Print(Mystring)
Delayms(50)
Wend
However when using USART2 only the carriage return and line feed characters are output, which can be viewed on an oscilloscope,
and seen on the terminal emulation program.
Public Sub Print(pStr as String)
USART2.Write(pStr, 13, 10)
end sub
MyString = "Hello World"
While (true)
Print(Mystring)
Delayms(50)
Wend
The following statement works correclty to USART2 and all characters are output.
USART2.Write("H","e","l","l","o"," ","W","o","r","l","d",13,10)
Therefore it would appear that when passing a string argument to my print function directed to USART2 the character string is somehow lost / becomes null.
Any help would be gratefully received.
- David Barker
- Swordfish Developer
- Posts: 1214
- Joined: Tue Oct 03, 2006 7:01 pm
- Location: Saltburn by the Sea, UK
- Contact:
I spoke to Danny about this via PM and suggested he post on the forum, as someone may have had some experience with this silicon. However, after reading his post again the clue is:
> USART2.Write("H","e","l","l","o"," ","W","o","r","l","d",13,10)
works because the routine would make multiple calls to USART2.WriteByte() whereas
makes a single call to
followed by 2 calls to WriteByte() for 13,10. I can now see the error:
PIR should be PIR3 - so
to make the changes:
(1) click on the USART2 entry in the explorer window
(2) double click on the padlock to unlock the file for editing
(3) find the above routine and change PIR to PIR3
(4) save the file and then close
this should correct the error for you.
> USART2.Write("H","e","l","l","o"," ","W","o","r","l","d",13,10)
works because the routine would make multiple calls to USART2.WriteByte() whereas
Code: Select all
USART2.Write("Hello World",13,10)
Code: Select all
Sub WriteItem(pText As String)
Code: Select all
Sub WriteItem(pText As String)
FSR0 = AddressOf(pText)
#if WDT
Asm
movf POSTINC0, W
bz $ + 12
ClrWDT
btfss PIR, 4
bra $ - 4
movwf TXRegister
bra $ - 12
End Asm
#else
Asm
movf POSTINC0, W
bz $ + 10
btfss PIR, 4
bra $ - 2
movwf TXRegister
bra $ - 10
End Asm
#endif
End Sub
Code: Select all
Sub WriteItem(pText As String)
FSR0 = AddressOf(pText)
#if WDT
Asm
movf POSTINC0, W
bz $ + 12
ClrWDT
btfss PIR3, 4
bra $ - 4
movwf TXRegister
bra $ - 12
End Asm
#else
Asm
movf POSTINC0, W
bz $ + 10
btfss PIR3, 4
bra $ - 2
movwf TXRegister
bra $ - 10
End Asm
#endif
End Sub
(1) click on the USART2 entry in the explorer window
(2) double click on the padlock to unlock the file for editing
(3) find the above routine and change PIR to PIR3
(4) save the file and then close
this should correct the error for you.
-
- Swordfish Developer
- Posts: 1473
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
Maybe I missed something, but in my copy of USART2.bas there's the following....
This seems to work ok to remap the use of PIR to PIR3, even in the asm block.
I THINK this is in the standard lib file...
Code: Select all
Dim // -> USART2
PIR As PIR3, // as PIR3
PIE As PIE3, // as PIE3
IPR As IPR3 // as IPR3
I THINK this is in the standard lib file...
- David Barker
- Swordfish Developer
- Posts: 1214
- Joined: Tue Oct 03, 2006 7:01 pm
- Location: Saltburn by the Sea, UK
- Contact:
-
- Swordfish Developer
- Posts: 1473
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
>> I'm at a loss as to why this silicon won't write a string using this routine via USART2
Me too.
FWIW, I've modified my usart/usart2 routines to just use
It's a tad slower than the inline asm, but since you're dealing with a uart you pretty much end up having to wait anyway. That way, if you modify WriteByte (to add parity or whatever) you don't have to change 'WriteItem(string)'.
You DO have to make sure that WriteByte leaves FSR0 alone.
Me too.
FWIW, I've modified my usart/usart2 routines to just use
Code: Select all
sub WriteItem(pText as string)
FSR0 = addressof(pText)
while (INDF0 <> 0)
WriteByte(POSTINC0)
end while
end sub
You DO have to make sure that WriteByte leaves FSR0 alone.
-
- Posts: 22
- Joined: Thu Sep 05, 2013 4:45 pm
- Location: United Kingdom
Further observations
It appears that on the 67J94 (97J94 family)
TXREG1 $FAD can be read and written to via the ACCESS bank as the address is higher than F60
TXREG2 $F1D can only be accessed by additionally setting the bank select register (BSR)
However setting breakpoints in the code, the BSR is always 0 when writing to USART2.
Disassembly listing for USART1
0007C 50EE MOVF 0xfee, W, ACCESS
0007E E004 BZ 0x88
00080 A89E BTFSS 0xf9e, 0x4, ACCESS // This is PIR1
00082 D7FE BRA 0x80
00084 6EAD MOVWF 0xfad, ACCESS // TXREG1 is written here
00086 D7FA BRA 0x7c
Disassembly listing for USART2
00084 50EE MOVF 0xfee, W, ACCESS
00086 E004 BZ 0x90
00088 A8A4 BTFSS 0xfa4, 0x4, ACCESS // This is PIR3
0008A D7FE BRA 0x88
0008C 6F1D MOVWF 0x1d, BANKED // TXREG2 is written to here and BSR is 0
0008E D7FA BRA 0x84
What controls the BSR for reading / writing the SFR's?
Are there any compiler directives in some of the ancilliary files?
TXREG1 $FAD can be read and written to via the ACCESS bank as the address is higher than F60
TXREG2 $F1D can only be accessed by additionally setting the bank select register (BSR)
However setting breakpoints in the code, the BSR is always 0 when writing to USART2.
Disassembly listing for USART1
0007C 50EE MOVF 0xfee, W, ACCESS
0007E E004 BZ 0x88
00080 A89E BTFSS 0xf9e, 0x4, ACCESS // This is PIR1
00082 D7FE BRA 0x80
00084 6EAD MOVWF 0xfad, ACCESS // TXREG1 is written here
00086 D7FA BRA 0x7c
Disassembly listing for USART2
00084 50EE MOVF 0xfee, W, ACCESS
00086 E004 BZ 0x90
00088 A8A4 BTFSS 0xfa4, 0x4, ACCESS // This is PIR3
0008A D7FE BRA 0x88
0008C 6F1D MOVWF 0x1d, BANKED // TXREG2 is written to here and BSR is 0
0008E D7FA BRA 0x84
What controls the BSR for reading / writing the SFR's?
Are there any compiler directives in some of the ancilliary files?
-
- Swordfish Developer
- Posts: 1473
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
>>TXREG2 $F1D can only be accessed by additionally setting the bank select register (BSR)
If that's the case then my modification posted above should work fine as it's the inline asm in 'WriteItem(string)' that's the culprit.
For usart2 WriteByte() will have the BSR set to 15 before it writes to TXREG2.
If that's the case then my modification posted above should work fine as it's the inline asm in 'WriteItem(string)' that's the culprit.
For usart2 WriteByte() will have the BSR set to 15 before it writes to TXREG2.
- David Barker
- Swordfish Developer
- Posts: 1214
- Joined: Tue Oct 03, 2006 7:01 pm
- Location: Saltburn by the Sea, UK
- Contact:
The compiler will handle RAM banking but note in the code sample it's ASM. Hence WriteByte() works, but the ASM does not as you need to handle RAM banking. This is a problem with some of the more recent 18F architectures. That is, SFRs are outside of ACCESS RAM.
In summary
(1) The compiler will handle RAM banking if the code is written in Swordfish
(2) The compiler will not handle RAM banking when code is in an ASM block
If it is an ASM RAM banking issue (and it looks that way) then Jerry's code will fix the problem for you.
In summary
(1) The compiler will handle RAM banking if the code is written in Swordfish
(2) The compiler will not handle RAM banking when code is in an ASM block
If it is an ASM RAM banking issue (and it looks that way) then Jerry's code will fix the problem for you.
-
- Swordfish Developer
- Posts: 1473
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
- David Barker
- Swordfish Developer
- Posts: 1214
- Joined: Tue Oct 03, 2006 7:01 pm
- Location: Saltburn by the Sea, UK
- Contact:
-
- Posts: 22
- Joined: Thu Sep 05, 2013 4:45 pm
- Location: United Kingdom
Problem Solved!
Thanks for all your prompt support gentlemen! Jerry's code works a treat.
I am really pleased that we managed to find the reason behind what was happening, so that we can be aware of this when using other libraries.
I am really pleased that we managed to find the reason behind what was happening, so that we can be aware of this when using other libraries.
-
- Posts: 22
- Joined: Thu Sep 05, 2013 4:45 pm
- Location: United Kingdom
Problem Solved!
Thanks for all your prompt support gentlemen! Jerry's code works a treat.
I am really pleased that we managed to find the reason behind what was happening, so that we can be aware of this when using other libraries.
I am really pleased that we managed to find the reason behind what was happening, so that we can be aware of this when using other libraries.
- David Barker
- Swordfish Developer
- Posts: 1214
- Joined: Tue Oct 03, 2006 7:01 pm
- Location: Saltburn by the Sea, UK
- Contact: