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

What are you doing about flow control ?

I've just quickly read the UART section of the PIC24F manual (it's not a part I've ever used before) and I see the PIC24F UART logic can stop transmission if the peer has raised CTS.

Is this your problem ?

Simon.

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

I can still send a reset command from the PC to the PIC, so the PIC receiver is still running.

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

If that's the case, then you really should check what you are doing with regard to flow control and what your peer is expecting.

Simon.

Ah - thanks!

-- Les Cargill

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.

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

Does the PC that you are using have a "true" serial port or are you working through a USB-to-RS232 converter? If the latter, who's USB driver are you using? I've experienced a similar "hanging" or "stalling" problem with both an older FTDI driver and a Prolific driver. Update to the latest FTDI drive fixed the problem. I switch to avoid the Prolific driver. In my scenario the RS232 port was still up, but communications stalled.

rks

=A0I can

to

bps

cle,

m.

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.