Strange problem with Serin/Serout on 16F628

Hello all, I have been fighting this for a few days now and I am baffled so I thought I'd toss it out to you all...

I am trying to communicate to a serial MP3 player via a 16F268 and just can't seem to get it to go. Here is the strange part. I have no problem communicating with the player when I use a 16F876A (with a 20 mHz resonator) or a 12F629 (using the internal osc). This tell me that my circuit design is fine. I run the same code (with the appropriate device-related changes) on the different chips - 876 & 629 work - 628 doesn't. I am using pins a.0 and a.1 for the communication pins on the 628 (with CMCON = 7). Does anyone see any problems with that? I have tried running the 628 with the int osc, with a 4 mHz and a 20 mhz resonator and no difference. Here is the code:

INCLUDE "modedefs.bas"

@ DEVICE pic16F628, XT_OSC
DEFINE OSC 4

CMCON = 7

TXPin var PORTA.0
RXPin var PORTA.1
Trigger var PORTB.3

TRISA.0 = 0
TRISA.1 = 1
TRISB.3 = 1

B0 var byte
CR CON 13 ' constant value of a carriage return

'************************************************* *******
PAUSE 5000 'allow module time to initialize
SEROUT txpin, T9600,["VST",CR] 'stop anything that's playing

Loop0:
if trigger = 1 then goto loop0 'button is pulled high via 10K resistor

SEROUT txpin, T9600,["VPF file000.mp3",CR] 'Play a file named "file000.mp3"
PAUSE 2000

SERIN rxpin, T9600, [">"],B0 'Waits for "<" to indicate playing done
PAUSE 2000
goto loop0

end

Like I said above, This same code runs fine on other PICs. Is there some issue with the 628's and serial communication that I'm missing. I've been scouring through related posts and don't see anything. The way my circuit is laid out, I am kinda restricted to using A.0 and A.1 on the 628. If there is some reason I should not use those, please let me know and I'll redesign my circuit.

Thanks!

Hi Atom058,
I have a couple of thoughts,
add a temporary blinky to your code to confirm PIC's operation, and check your breadboard, maybe it has some bad connections, I have had my share of headaches from that.

Joe - Thanks for your reply - On this board I have built, I have other components - a pot, an LED and a hex switch. I have been able to write snippets of code to test all of those individual items and everything works fine. The only circuitry involved with communicating with the MP3 player are 2 copper traces that go from the pic pins to the connector that the player plugs into (about 1/4" long each) - very straight forward. As I mentioned earlier, I had this working on 2 other boards that used different chips (and it still works) so it is not the player or the program. It just seems to have something to do with me using the 628. I would go back to using the 629, but I need more I/O and using the 876 is overkill. The 628 is perfect, I/O wise... I just can't figure out why it is different...

16F628 or 16F628A?

I don't know if this is any help but RB3 is also CCP1. There are some conditions when this may be a problem if RB3 and RB4 are both pulled low. I don't know what other pins you have connected in your circuit but it may be worth checking the CCP1CON register setting. Its also worth checking that Low Voltage Programming is disabled as this sometimes causes problems if the PGM pin is floating. Hope this isn't too far off the mark to be of some use.

Mike

Skimask - it is a 628 - not 628A.

Mike - I'll look into your comments and get back. Thanks!

Quote:

---

Originally Posted by Atom058

Skimask - it is a 628 - not 628A.

---

Are ya sure you're compiling/assembling for the 628 and not the 628A? :)

I would never bet on the reliability of SEROUT @9600 baud @ 4MHz... manual says black on white that you should use higher speed crystal. Try DEBUG/DEBUGIN.

Better if you use the INTERNAL USART with hserin/hserout...

Well, don't ask me to explain it, but moving TX and RX connections to B.6 and B.7 solved my problem. I tried A.0 & A.1 and B.0 and B.1 and nothing. B.6 & B.7 works just fine... I would be interested if anyone could explain that one! ...

I didn't want to use HSERIN and HSEROUT as the manual says the I need to use a MAX232. Trying to keep cost and size down.

But as usual, thanks to all that offered input!

I can understand that you need to keep the cost down, but be aware that - while it may work 90% of the time, the output of the PIC does not meet RS-232 specs. I have occasionally come across computers that would not respond to the PIC's output. Running without a level shifter is OK in the lab, but I wouldn't recommend that you produce a commercial product that way.

Not all pins are created equal. On the 16F628 RA0 and RA1 are ST "Schmitt Trigger"
type buffers.

If the RX pin isn't seeing 0.8 * Vdd (around 4V with Vdd = 5), it wont see high enough
signal levels when receiving serial data. This can also be affected by external capacitance.

I.E. even with a TTL type input, external capacitance on the pin can degrade the serial
data to where it fails.

One the16F876A RA0 and RA1 are TTL buffer types, and the incoming signal only needs to
swing from ~2V to ground.

For reliability, like mister_e already mentioned, you definitely should go with a >4MHz osc
if you're using 9600 or greater.

PIC16F88 would be a better choice, internal osc can run up to 8MHz AND you can fine-tune it... for what it worth as it's an RC osc :eek:

The saga continues...
For a new design, I am using a PIC16F877A and trying to communicate serially with this same MP3 player - essentially running the same code that I had on the 628. You will recall that I "solved" my problem with the 628 design by moving my serial RX an TX pins from PORTA.0 and A.1 to B.6 and B.7. Bruce explained that my problem was due to A.0 and A.1 being Schmitt Trigger (ST) type buffers instead of TTL. I am assuming that what he is implying is that if your pin is a ST, you can not use it for serial communication. Is that correct?

For my new design on the 877a, I had intended to use pins E.1 and E.2 for communication but, alas, they are ST... I tried moving the serial comm to pins A.2 and A.3 which are TTL and still do not seem to be able to talk to the player. Right now, I am not using a MAX232, just going straight from the PIC pins to the TX and RX pins on the player - just as I am doing with the 628 design. It works on that board, but not on the 877. BTW, I am running both at 20 mHz.

Can anyone shed some light on this?
Thanks!

Quote:

---

I am assuming that what he is implying is that if your pin is a ST, you can not use it for serial communication. Is that correct?

---

Nope. If you're using an ST type input this just means that your external device sending serial data to the PIC has to meet the minimum input threshold levels for the ST input.

As for the portA pins, have you disabled A/D so you can use these pins as digfital inputs?

Bruce - Thanks for your reply. What you said is starting to make sense... For a ST pin to recognize input, it has to reach ~4V. For a TTL pin to recognize input, it has to only reach ~2V. Is that correct? So what you are saying is that in order to use a ST pin for serial input, the "signal" needs to be ~4+ Volts. And I am assuming that in most cases this would require a MAX232 to achieve those levels. Correct?

OK, let's just forget about the input for the time being. Can I use a ST pin for TXmit without any problems? Right now, the program transmits (supposed to) the commands to start playing when it receives a trigger. Well, I don't seem to be able to do that either. Any thoughts?

Here's my code:

Code:

---

    INCLUDE "modedefs.bas" 'Needed for serial communication

@ DEVICE HS_OSC              ; Hi Speed Osc 

    ADCON1 = 7          ' Set PortA Pins as I/O pins
    CMCON = 7

    Trigger    var PORTC.6
    PlayLED    var PORTD.1

    TXPin      var PORTA.2 'E.1
    RXPin      var PORTA.3 'E.2
   
    B0          var byte
    CR          CON 13      ' constant value of a carriage return

'****************************************************************

    low playled
   
'****************************************************************   
    PAUSE 3000                              'allow VMusic2 to initialize
    SEROUT txpin, T9600,["VST",CR]          'stop anything that's playing
   
'****************************************************************
Loop0:
    if trigger = 0 then goto loop0 'button is pulled low via 10K resistor
   
    high playled
    SEROUT txpin, T9600,["VPF file000.mp3",CR] 'Play a file named "file000.mp3"
    PAUSE 2000
   
    SERIN rxpin, T9600, [">"],B0 'Waits for ">" to indicate playing done
    low playled
    PAUSE 2000
    goto loop0

end

---

Look in the Electrical Characteristics section of the PIC data sheet. Look under Input
High Voltage. For a Schmitt Trigger type input you'll see something like 0.8 Vdd under
the Min column with Vdd under the MAX column.

What this means is; Minimum input that will be recognized as a logic 1 would be about
0.8 times Vdd. The MAX input level of course should not exceed Vdd.

Now look a bit farther to the right under Conditions. If this states "for entire Vdd range"
then this means 0.8 times whatever voltage you're operating at, that is within the spec
for Vdd, would be what you use for the input threshold calculation.

I.E. if the PIC you're using can operate from say 4V to 5.5V, then you would use whatever
Vdd is to figure this out.

Let's assume you're using a 4V supply. 0.8 * 4V = 3.2V. This would be the minimum input
level you need on the ST input to be recognized as a solid logic 1. This is the logic 1 input
threshold level.

Now look at the TTL input requirement. It may look something like this. Under the Min
column it shows 2. Under the Max column it shows Vdd. To the right it may be something
like 4.5V ≤ VDD ≤ 5.5V

2V is the minimum input level that will be recognized as a logic 1. Vdd is of course the MAX.

The 4.5V ≤ VDD ≤ 5.5V means (if Vdd is greater than or equal to 4.5V and less than or
equal to 5.5V), then you're operating within spec.

Output levels are also listed just below this section. A pin outputting a logic 1 will normally
be Vdd-0.7V, which just means you can expect a drop of around 0.7V due to the output
driver. If you're operating at 5V, then 5V-0.7V is what you can expect the output pin to
deliver to the load.

Quote:

---

Can I use a ST pin for TXmit without any problems?

---

Yep. ST only refers to input pins. The DC Characteristics section of the data sheet will
show what you can expect for a drop in the output driver. Normally it's around Vdd-0.7,
but it never hurts to check.

Bruce - Thanks for your elegant explanation - I now perfectly understand the difference between ST and TTL level inputs. Nicely stated!

And what you said about ST pins being used as xmit pins indicates that I should probably not have a problem doing that (I'm running at 5V, btw). Did you see any problem with my code as to why I don't seem to be transmitting to the player? Since I am not using a 232 chip, I am using the T9600 command (as opposed to the N9600 command). The Xmit and RCV pins (A.2 and A.3) are wired directly to the Xmit and RCV pins of the player. Should I be doing anything special with these connections? Like I said earlier, this works fine on my 628 board.

I appreciate your help. I am at wits end - it just doesn't make sense... Thanks!

How do you know that you're not transmitting data to the player?

Have you looked at the tx output with a scope? Have you tried inverted mode?

Could be your player requires inverted serial. That would explain why it isn't responding.

Edit: You show @ DEVICE HS_OSC but you don't show any DEFINE OSC. If you're using
anything other than 4MHz, you'll want to define that oscillator speed. PBP assumes 4MHz
unless you specify otherwise, and that will for sure screw-the-pooch with timing if you're
not using a 4MHz osc. If you are using a 4MHz osc, you may want to switch to @ DEVICE
XT_OSC so you're not over-driving your 4MHz osc.

Bruce - When it gets the valid command to play the sound clip, it plays. There is a status LED on the player that flashes when it gets the comand. It does not do that. I can take this player off the 877 board and can put it on the 628 board running the same code and it works fine. The only difference is that I am using A.3 and A.4 on the 877 for communication and B.6 and B.7 on the 628 board. Everything else is the same. That is what is so frustrating - it's like rotating your tires and now your car won't start. Rotate them back and everything works fine! Makes no sense!

Thanks again for all your help!

Interesting problem. You seem to have everything configured OK for A/D & comparators off
with ADCON1 = 7 & CMCON = 7. Have you verified the PIC is even running by blinking an LED?

Edit: hold the phone. Your code indicates you're using A2 for TX and A3 for RX.

Quote:

---

The only difference is that I am using A.3 and A.4 on the 877

---

If you're using A4 for TX, this pin is an open drain output. I.E. it can't go high!

Maybe, just maybe.
http://www.picbasic.co.uk/forum/showthread.php?t=562

I might be wrong But I do not think A.4 will work for tx.


edit
Better late than never, did not see the above post

A4 can be used for an output, but it only goes high if you use an enternal pull-up resistor.

Ya know - I really cringe when I have to finally break down and have to ask for help from you guys on the forum because when you figure out what my problem is, it is usually me doing something stupid (again). And this is the case once again. Bruce hit it on the head. I left out the "Define OSC 20" statement. I put this in and it now talks to the player just fine. I am using pins A.2 and A.3 (not A.4 - sorry about the typo). I even reverted back to using E.1 and E.2 and it still works just fine. It was that statement all along! Nothing to do with ST's (although I did learn something).

Thanks so much for your help! No telling how long it would have taken me to find that since I was not looking in the right place. Always helps to have a fresh pair(s) of eyes to look at stuff! Hopefully, someone will learn from this as well.

Thanks again!!!

Quote:

---

Originally Posted by Atom058

Ya know - I really cringe when I have to finally break down and have to ask for help from you guys on the forum because when you figure out what my problem is, it is usually me doing something stupid (again).

---

We have all been there, and I bet I will be there again in an hour or two. :D
This is what the forum is for.