Serial port throughput

sound unlikely, the part is rated for 120kbps with 0.1uf caps you probably have a bug in the code have you checked the signal on the pic side of the max3232 with a scope?, or maybe just by toggle an led for every byte/block sent?

-Lasse

I presume you're using a circular buffer - putch or suchlike to insert characters and the interrupt extracts them.

Do you have BufOp (the interrupt output pointer) declared as volatile? Check that every time you add a character to the buffer that you enable the TX interrupt and that you ONLY extract characters in the interrupt routine and don't try and output a character directly if the UART is currently not busy. You should be getting throughtput of closer to 90kbps.

an

It's not interrupt driven. Actually, i am using the Microchip sample code to slow down the port:

U1TXREG =3D ch; Nop(); while(U1STAbits.TRMT =3D=3D 0);

If I want to speed it up, i would use:

while(U1STAbits.TRMT =3D=3D 0); U1TXREG =3D ch;

But i have to fix the shutdown problem first.

On a sunny day (Fri, 30 Sep 2011 09:56:36 -0700 (PDT)) it happened linnix wrote in :

First it is 115200 Bd

Maybe with the wrong baudrate you get framing errors on the Rx side.

Scope PIC output, and scope Max output. That should tell you if the signal dies in the MAX.

Line capacitance to ground (shield?) is very important too at those speeds. Make sure you have nice rectangular blocks there.

You could try 2 stop bits and not 1 to give the receiver some more timn. Are you checking the tx register for empty before sending the next byte? Is any funny interrupt in your system crashing or altering the UART configuration? etc etc etc. Measure do not guess.

Yes, it's 115200. I just didn't bother to mension the 200.

If i can borrow a scope, i haven't use one for a while. Anyway, i'll try to verify the logic some other way: LED, other ports.

s.

But the PC is more than capable of receiving over 115200.

Yes, see previous post.

guration?

USB host stack is running in interrupt, but it should not be touching the UART.

Apparently a software bug or a protocol lockup. The 115200 baud is no problem neither for PIC nor for MAX3232.

VLV

I have come across non Maxim 232 parts that fall over at 115200 baud.... I think you need a scope on it or some debug equipment....

Then the transmitter has shut down. That's the circuit on the PIC24/Max232 side. It might even be the UART.

Try varying:

- the baud rate

- insert delays on the transmit side every block.

- only allow the xmit FIFO to get so full.

and see if one or more strategies makes the stoppage go away.

I don't have the device in front of me, but a Max232 (not a 3232 - haven't used those yet ) should merrily twiddle the transmit pin without being connected, so ...

I'd also check to see if there's a problem with the baud clock generator on the embedded side. Sometimes the divisor gets small for 115,200 and you'll get latch-ey behavior. This is very hand-wavey, so...

What does that mean? DCD or something?

This sounds like you can back off the baud rate if you need to then.

Scope it. There should be a pin you can watch on the Max3232 to indicate that it's transmitting; put that and the cap. charge on a scope and see if the cap charge voltage goes out. I would think that if is were a cap. discharge failure mode that it would be more periodic, but that's not necessarily so. The data pattern may influence duty cycle.

So I'd repeat exactly the same data pattern for every 4k block and see if the shutdown time gets more constant.

Make sure you have good signal ground connections, too.

-- Les Cargill

Yes, it's a TI clone. Perhaps i need to check out others. My guess is that the charge pump is not suppling enough voltage for the transmitter.

That's unlikely, first of all because if that were the case, the correct function would resume after a brief pause to allow the caps to recharge. But you say that only a reset enables TX again.

That's usually a clear indication that something's wrong with the code.

I'm not familiar with the 24, have you checked the possible failure modes for the USART module? Does your code check there is enough space in the USART TX buffer before placing a new byte? Does you code clear any fault bit?

Claudio

ages. =A0

Sounds unlikely, but very easy to check with a couple of LEDs, one on the uC and one on the RS232. Since RX seems OK, I'd try a sustained uC-only TX, continual send 55H "U", and a frequency counter can show you gaps, or any disturbances. Start with a tiny self-loop TX, and then use more and more of your original code.

s

can

ps

e,

Which particular PIC24? Are you sure it isn't the routine feeding the data to your TX routine? As you say, it can't get much simpler :)

Making a note to remember this. A true embedded scholar ... ;)

-- Roberto Waltman

[ Please reply to the group, return address is invalid ]

rks

=A0I can

to

bps

cle,

m.

e t ? e

PIC24FJ256DA206

I wish life is that simple. Just when i am trying to get back to test it. My drive crashed, along with all the MPLAB tools. Got another drive, with flesh XP. But MPLAB no longer install on the same XP in the same computer. LONG WEEKEND waiting for Microchip support.

I hated the AVR tool's dependencies on JRE, but at least i know how to get around it.

Don't know how to deal with MPLAB, .net2, netbean or whatever.

I have come across non-Maxim parts that locked up if too much current is taken from the charge pump voltages. We had a card once that "borrowed" the V+ voltages for a additional signal. It worked fine with the Maxim

232 parts, but failed with an alternative part. If we drew too much current from the charge pump, it shut down and had to be power-cycled to get it working again.

Of course, that shouldn't happen when running at the rated baud rates - unless for some reason there is more load on your RX line than there should be.

First of all: check the signal on the output of the MAX3232 if that shuts down. Probably not. Is your baudrate exactly 115200? If not, you HAVE to insert silent periods of at least one byte time to let the receiver resync on an idle state. If you send data over an async line and the baudrates don't match exactly, you end up with sync problems.

Meindert

an

s

ou

I am clocking with 12MHz crystal, 96MHz PLL and 32MHz CPU, so timing should be OK. I have to insert turn around delay, "put char" ->

delay -> "get char". as well as transmitter empty checking: "put char" -> "check transmitter empty" (reverse order will not work) to get it to work.

So, something is stopping it from running full duplex at full speed.

works

=A0I can

to

bps

cycle,

problem.

shuts

periods

If

exactly, you

Me suspects you never get to the problem without a scope. Hunt places like Craigs list, eprey, yard sales, surplus outlets for minimal scopes = to do the job, maybe real cheap 'bout $10.

Pidgin special cheap advice.

?-)

ks

I can

o

bps

le,

.

uts

iods

If

, you

o

More like $100 to $200, and another piece of junk, according to my wife.

Yes, we would need to scope it piror to productions. The production shops should have the equipments to do so.

For now, just looking for easy fix. I am going to try the Max232 (upto 250Kbps) rather than the Max3232 (up to 120Kpbs). We just change the VCC from 3.3V to 5V, so we don't need the Max3232 anyway.