USART2 Problem 67J94

[DannyScott]

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.

[David Barker]

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

Code: Select all

USART2.Write("Hello World",13,10)

makes a single call to

Code: Select all

Sub WriteItem(pText As String)

followed by 2 calls to WriteByte() for 13,10. I can now see the error:

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

PIR should be PIR3 - so

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

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.

[Jerry Messina]

Maybe I missed something, but in my copy of USART2.bas there's the following....

Code: Select all

Dim                                // -> USART2
   PIR As PIR3,                    //    as PIR3 
   PIE As PIE3,                    //    as PIE3
   IPR As IPR3                     //    as IPR3

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...

[David Barker]

It that case, I'm at a loss as to why this silicon won't write a string using this routine via USART2.

[Jerry Messina]

>> 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

Code: Select all

sub WriteItem(pText as string)
    FSR0 = addressof(pText)
    while (INDF0 <> 0)
        WriteByte(POSTINC0)
    end while
end sub

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.

[DannyScott]

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?

[Jerry Messina]

>>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.

[David Barker]

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.

[Jerry Messina]

>>That is, SFRs are outside of ACCESS RAM.
Gee, you mean Mchip keeps changing things every time they release a new chip? I've NEVER seen that happen...

Writing libraries for these things could be a full-time job!

[David Barker]

> Gee, you mean Mchip keeps changing things every time they
> release a new chip



> Writing libraries for these things could be a full-time job!

That's one reason why Swordfish libraries are open - at least you get a chance to adapt to these changes!

[DannyScott]

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.

[DannyScott]

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.

[David Barker]

Glad you are up and running.

Most of the libraries are written in Swordfish, rather than shelling out to ASM - so you should be OK. As mentioned earlier, the module code is open so you can always take a look at the source code if you encounter any further problems...