PIC Embedded C printf Corrupted Output - Very odd - c

Question

I have a 69 element array MBRespon[i] of hex data which I'm sending out of two USARTs on a PIC18F46K40. The first USART loops through the data and transmits everything fine, and when that's done the code goes through a 2nd loop where it prints the formatted data out of the 2nd UART using:
printf(" Byte %02i : 0x%02x \r\n", i, MBRespon[i]);
At first it looks like the data is being printed out fine, however upon closer inspection around the 57th byte it sends the wrong thing. At first I thought this might have been a EUSART2_TX_BUFFER_SIZE issue, and indeed changing the buffer sizes does have a impact; more gets corrupt when it's anything different than 32.
#define EUSART2_TX_BUFFER_SIZE 32 // 32 Works (Sort of)
#define EUSART2_RX_BUFFER_SIZE 32 // 32 Works (Sort of)
If i reduce the number of elements in the array to 58 or less it's fine, anything more and it's corrupt.
My code:
void PrintModRespon(){
int i=0;
printf("Modbus Response Count %i:\r\n",MBResCnt);
while(!EUSART2_is_tx_ready()); // Hold the program until TX is ready
for(i=0; i< MBResCnt ; i++ ){
while(!EUSART2_is_tx_ready()); // Hold the program until TX is ready
printf(" Byte %02i : 0x%02x \r\n", i, MBRespon[i]);
while(!EUSART2_is_tx_done()); // Hold until done.
}
while(!EUSART2_is_tx_ready()); // Hold the program until TX is ready
printf("\r\n\n");
while(!EUSART2_is_tx_done());
}
I added in while(!EUSART2_is_tx_ready()); and while(!EUSART2_is_tx_done()); as I thought it may be the UART wasn't ready/busy, but they didn't make any difference.
UART1 Output (The good one):
06 03 40 00 01 00 02 00 03 ....etc.... 00 1a 00 1b 00 1c 00 1d 00 1e 00 1f 00 20 5c 30
UART2 Output (The bad one):
Modbus Response Count 69:
Byte 00 : 0x06
Byte 01 : 0x03
Byte 02 : 0x40
Byte 03 : 0x00
Byte 04 : 0x01
Byte 05 : 0x00
Byte 06 : 0x02
Byte 07 : 0x00
Byte 08 : 0x03
..etc...
Byte 53 : 0x00
Byte 54 : 0x1a
Byte 55 : 0x00
Byte 56 : 0x1b
Byte 57 : 0x14 // <-- This is NOT in the array!
Byte 58 : 0x1c
Byte 59 : 0x00
Byte 60 : 0x1d
Byte 61 : 0x00
Byte 62 : 0x1e
Byte 63 : 0x00
Byte 64 : 0x1f
Byte 65 : 0x00
Byte 66 : 0x20
Byte 67 : 0x5c
Byte 68 : 0x30
Oddly, as another test, I changed the printf function to:
printf(" Byte %02i : 0x%02x \r\n", i, 0x00 +i);
I.E Not using the array of data, and it output 69x incremented values fine! Which suggests it's not a UART buffer/timing issue?
Modbus Response Count 69:
Byte 00 : 0x00
Byte 01 : 0x01
Byte 02 : 0x02
...etc.
Byte 51 : 0x33
Byte 52 : 0x34
Byte 53 : 0x35
Byte 54 : 0x36
Byte 55 : 0x37
Byte 56 : 0x38
Byte 57 : 0x39
Byte 58 : 0x3a
Byte 59 : 0x3b
Byte 60 : 0x3c
Byte 61 : 0x3d
Byte 62 : 0x3e
Byte 63 : 0x3f
Byte 64 : 0x40
Byte 65 : 0x41
Byte 66 : 0x42
Byte 67 : 0x43
Byte 68 : 0x44
Any suggestions greatly appreciated. I've been stuck on this for days now!

Answer 1

This is very likely a padding issue since the first element of your structure has an odd number of bytes.
When defining structures, the compiler will create one-byte padding between elements if they do not fall on the default alignment of the processor. A 16-bit processor will want most things aligned on word boundaries (i.e. even addresses), including byte arrays (e.g. arrays of char). The exception is elements that only occupy one byte.
On a 16-bit Microchip MPU, if you try to access word or dword data on odd address, it will cause a memory fault. The compiler is trying to keep this from happening.
If your structure only contains byte-sized elements (char, uint8_t, etc.), or arrays of the same, you can force byte alignment by adding the qualifier __attribute__((packed)) to the structure declaration. This can be dangerous because you may end up with elements having odd addresses. This is OK as long as the odd-addressed elements are only accessed as bytes (e.g. a char array), but proceed with caution.