Atmega 128 Serial

[Alan_37]

Hello,

I believe there's a bug in the UART receive function on the ATmega128A. It seems that the 0x00 byte is being interpreted as a string terminator, causing the reception to stop prematurely.

For example, if I try to receive the following byte stream:
23 1B 44 66 00 21 63 1E
Only these bytes are received:
23 1B 44 66

However, if the data stream doesn't contain 0x00, the entire message is received correctly.

Interestingly, I also tried receiving the data byte-by-byte using the following C code, but encountered the same issue:

Code: Select all

MX_UINT8 i = 0;
for (i = 0; i < FCV_RX_SIZE; i++)
{
    FCV_U1_CHAR = FCD_047b1_UART1__ReceiveChar(20);
    FCV_U1_RX1[i] = FCV_U1_CHAR;
}

It seems the problem is not with the loop logic, but possibly with how 0x00 is handled internally — maybe it's treated as a null terminator somewhere in the stack.

I'm stuck at this point. Any advice or workaround would be greatly appreciated.

Thanks in advance!

[mnfisher]

Hi Alan,

That looks odd - I wouldn't expect a big timing difference with 0 compared to other chars... How is the IART set up too (ie can you post a chart that demonstrates this)
ReceiveChar 'should' allow reception of a 0 - have you tried using an UartRX interrupt handler. This would stuff data into an array or circular buffer.


Martin

[Alan_37]

Hi mnfisher

The ReceiveString function is in a UartRX interrupt Baud is 1200 and is set by the following code

Code: Select all

// Disable USART transmitter and receiver
UCSR1B &= ~((1 << TXEN0) | (1 << RXEN0));
FCV_UART_1_STATUS [0] = 0;

//Set Baud XTAL @16Mhz
UBRR1H = 0x03;
UBRR1L = 0x40;
FCV_UART_1_STATUS [1] = 1200;

//Set Data Bits
UCSR1B = (0 << UCSZ12); 
UCSR1C = (1 << UCSZ11) | (1 << UCSZ10); 
FCV_UART_1_STATUS [2] = 8;

//Set Parity 
UCSR1C |= (0 << UPM11) | (0 << UPM10); 
FCV_UART_1_STATUS [3] = 0;

// Enable USART transmitter and receiver
UCSR1B |= (1 << TXEN1) | (1 << RXEN1);
FCV_UART_1_STATUS [0] = 1;

As for the circular buffer, I am using a string Array to store the data it always worked this way.

[mnfisher]

Please upload an fcfx file (save me some typing and some guessing) as you are using the part component is the extra set up necessary?

I would receiving a single character per interrupt and add to received data (array is fine of course)

How are you 'marking' the end of input (is it fixed length or do you have an end character?)

Also:

How is the data being sent - if you are using 'send string' then 0 will mark the end of data?

Martin

[Alan_37]

Hi Martin,

Sorry can not share the FCFX file,

> The additional setup is required to change non-standard baud rates during runtime.
> Receiving a single character per interrupt is a good idea, I have not tried that .
> For each unit & Brand, the expected byte count is known, but a timeout is also used to ensure the program doesn’t get blocked.
> Data is being sent from an air conditioner outdoor unit ( a Renesas MCU RX62T7 )

It would be great if we could customize the termination byte in the UART settings, in my case that
would only help to receive the full data stream, as the last byte in the communication is almost always
a checksum calculation so it's never the same.

[mnfisher]

Can you share a snippet that demonstrates?

I would recommend receiving a single byte per interrupt - there needs to be some termination 'technique' A count is AOK - and 'as an idea' - pass this as the first byte (or word depending on data length) Using a termination character is okay if it cannot occur in the data - so for example an ASCII string might use Ctrl-Z, /0 or /r as the termination - the interrupt handler can check for this....

Just been playing with a 4g module - and here using a timeout is also an option (so, say, receive data for 1s)

It's easier - if you have control over the data being sent You might not in this instance?

If receiving data into an array - remember to wrap / stop receiving when full to stop (possibly malicious) overflow situations...

I usually use something like (in the interrupt):

.c = GetChar(0);
data[pos] = .c
pos = (pos + 1) % buf_size
data_recvd = (.c == termination_char) (or pos >= data_size)

Then in the progran:

if(data_recvd) then

..



Martin

[Alan_37]

Hi Martin,

After giving it some thought, I realized that many C functions stop processing a string once they encounter a null character. That’s likely the issue when trying to store the data in a string array.

I’ll try storing the data in a byte array instead and see how that works out.
I really appreciate your effort in helping me with this!

Thanks

Alan

[mnfisher]

Yes, most likely a string function used at some point...

I did a small trial last night, and 0 received correctly - I'll post the code later, but it outputs anything received at UART as bytes and a string.

So sending 41 42 0 43 44 45(hex)

Gives A B when displayed as a string and

AB CDE when displayed as an array of bytes..

Martin

[Alan_37]

Hi Martin,

Storing the data in a byte array worked perfectly for me. I can always convert it to a string when needed.

To be honest, I was trying to avoid that at first, since it would require changing a lot of existing code—but in the end, this approach makes more sense, especially since I’m mostly dealing with binary data.