Part Number: TMS320C6657
Tool/software: TI C/C++ Compiler
Dear TI Support Team,
I am working with latest C66xx compiler 8.2.3 on my own C6657 board.
Normally the SPI boot works correctly. Now I will use LZSS compression for some selected sections. As result of LZSS compression the generated xxx.load section has a size not multiple of four bytes, in my case 0x00000072 bytes.
After running the hex6x tool I can see in the generated btbl file, that hex6x appends some padding bytes to get a data size multiple of 4 bytes. This is my LZSS compressed section for reference:
00 00 00 72 9B 53 98 80 00 2A FD 00 48 0A 25 0F 6F 6C 6C 65 6F 77 20 FF
2C 64 6C 72 68 74 DF 0A 00 20 73 69 FF 20 61 20 70 6D 69 73 74 20 65 6C
74 73 65 FF 72 74 73 20 67 6E FF 69 20 6F 74 20 65 FF 68 63 74 20 6B 63
FF 74 61 68 4E 49 42 20 6C 20 54 49 64 61 6F D7 03 0A B0 01 FF 68 74 60
61 73 20 65 61 20 65 6D 43 20 73 B7 0A 2E C9 01 00 27 CF 09 17 0F 00 00
00 00 F0 FF
You can see length = 0x00000072 and load = 0x9B539880. All data in the BE format. The last two bytes F0 FF forms the LZSS end marker and the both 00 00 before are the padding from hex6x tool.
If I run such section inside of RBL then the expected end of section is not FF F0, instead the RBL writes 00 00.
I have taken a look in the RBL sources (gem.c file) and I find out that the function coreCopyData() has a different behavior in case of sections with padding. Look at line 112 and following:
if ((CSR & C64X_REG_CSR_BIT_EN) != 0) {
/* Little endian. Put remaining bytes in the least significant value */
if (rb >= 1) {
insert = (p_data[j] >> 8) & 0x00ff;
value = (value & 0xffffff00) | insert;
}
if (rb >= 2) {
insert = p_data[j] & 0x00ff;
value = (value & 0xffff00ff) | (insert << 8);
}
if (rb >= 3) {
insert = (p_data[j+1] >> 8) & 0x00ff;
value = (value & 0xff00ffff) | (insert << 16);
}
} else {
The same situation can occur for the .const section.
Do you have any workoraund to get the RBL working correct in case of sections with padding, or how I can avoid such padding for auto generated sections?
Kind regards
Sven
