RS232 TX Buffer overrun???

[tinley]

I have checked all over the documentation and can't find an answer to this question: How does the compiler assign a buffer to RS232 TX? My application has a declared large input buffer and transmits large amounts of Data on an 18F2550. The pic halts, apparently because the TX buffer is using more ram than is available. I think I prove this by reducing the size of the input buffer/s, so allowing more space... but I require the biggest buffers I can get! And I want to understand fully when the pic might crash. The program is using USB and a bootloader and is complied with 4.081:

[Ttelmah]

The compiler doesn't.
Transmission is unbuffered, excwet for the internal hardware buffering in the chip (two characters for most PICs).
Look at ex_stisr.c, for an example of buffered transmission, and the code needed to do this. As a 'comment' though, don't use 300 bytes with this code. Either switch to a binary size (64/128 bytes), or perform the buffer overflow test as:

[tinley]

The problem seems to be caused by the complier sending data before the UART is ready to receive it. It is NOT caused by the way the buffers are used, as it happens by them simply being there.

This following workaround runs, so I am sorted, but is there a bug to be fixed??

printf(txBuffer);
delay_uS(1);

Note that delay_cycles( 200 ); does not work, even though it amounts to longer than 1uS.

Is this because delay_uS(1); becomes longer, (long enough), due to the UART TX interupts?

[Wayne_]

"Now when I try transmitting lots of data without USB connected, the pic halts, (or watchdog reset if enabled). If USB is connected, software runs without fault. "

So this snippet of code you have posted does NOT fail, as it is not in my opinion sending lots of data.

Also, where is the USB code included ?

You are not using a tx interrupt somewhere are you ?

[tinley]

This snippet DOES fail, because the data is being sent in a loop. This snippet does not crash the processor though... it just corrupts the data.

Is it possible that this data is actually corrupted by Hyperterminal?

I which case I've been led up the garden path and the bug is in the main program is elsewhere. The snippet was to proove the compiler, before spending more hours on my code!!!

I haven't shown the USB code, as the snippet fails with or without it.

No, I'm not using the tx int. I assume that CCS use this anyway.

In further answer to Ttelmah, I do not need or want a TX buffer, as the buffering is done on the 2 inputs.

Thank you for your help!

[Wayne_]

You initially said the pic stops or if the WD is enabled it is reset.
Now you are saying the data that is shown on hyperterminal is corrupt!

There are no linefeeds or carrige returns "\r\n" being output which would mean the data is displayed on one line of hyperterminal, unless it is wrapping around. you are proberbly seeing the data overwrite itself on hyperterminal which is why it looks like it is getting corrupted.

if it fails without the USB code then remove the if statement and just output to hyperterminal!

I don't believe CCS uses the txint unless you use one of the libraries for buffered output (bputc).

[tinley]

Thanks Wayne,

The bug in the main software is that it halts... but only if the buffers declared are large.

I tried to proove this was an overrun of the TX in some way with the examples given.

As you say, I expect the data to be displayed on one line, which it is. However, after some 5-10 secconds, the data becomes very corrupt. I don't know:

1. If this is Hyperterminal or the Pic
2. If this is causing the bigger program to crash.

Actually I did remove the if usb coonected else... it still produces garbage on hyperterminal.

The program is now running, but it still freezes if I use buffers bigger than about 275 bytes. The trouble is the bigger the buffers the more likely it freezes, so I don't know how big they can be for them to never freeze? They froze once in ten minutes at 275 bytes and 275 is barely big enough.

[Wayne_]

When you build it what is the memory usage reported ?

[tinley]

98-100%

Also, could you please clarify where I might find info in the binary buffer size... although this seems to make no difference in my application?

Cheers