I am trying to use the grlib provided with the AM335x Starterware. The first call I make is to GrOffScreen1BPPInit , which is in offscr1bpp.c. In that function, the instruction
*(unsigned short *)(pucImage + 1) = lWidth;causes an un-aligned access, hence the trap. pucImage is a passed parameter defined as:
unsigned char g_pucBuffer[GrOffScreen1BPPSize(DOC_WIDTH, DOC_HEIGHT)];
where the GrOffScreen1BPPSize macro is defined in grlib.h as:
#define GrOffScreen1BPPSize(lWidth, lHeight) \ (5 + (((lWidth + 7) / 8) * lHeight))
So it appears that the buffer is intentionally defined with a 5 byte header, then unaligned accesses used to populate it.
Is this a known bug in grlib?
Not sure this can help.
In demo example this is missing, probably because GrOffScreen24BPPSize is always aligned, but in other examples you can find:
// Memory that is used as the local frame buffer.#if defined(__IAR_SYSTEMS_ICC__)#pragma data_alignment=4unsigned char g_pucBuffer[GrOffScreen24BPPSize(LCD_WIDTH, LCD_HEIGHT, PIXEL_24_BPP_UNPACKED)];#elif defined __TMS470__ || defined _TMS320C6X#pragma DATA_ALIGN(g_pucBuffer, 4);unsigned char g_pucBuffer[GrOffScreen24BPPSize(LCD_WIDTH, LCD_HEIGHT, PIXEL_24_BPP_UNPACKED)];#elseunsigned char g_pucBuffer[GrOffScreen24BPPSize(LCD_WIDTH, LCD_HEIGHT, PIXEL_24_BPP_UNPACKED)] __attribute__ ((aligned (4)));#endif
In reply to Qmax:
I agree that the alignment problem does not exist in the 24BPP routines. An even number of bytes is pre-pended there, and the width variable is at offset 0.
That said, I have made progress. In grlib.h there is a macro, GrImageWidthGet, which gets the width a byte at a time. There is no corresponding PUT macro.
After a failed attempt to write one, I brute forced the initialization:
// The following are un-aligned in the buffer: // *(unsigned short *)(pucImage + 1) = lWidth; // *(unsigned short *)(pucImage + 3) = lHeight; // so we need to put them in the little-endian hard way *(pucImage + 1) = lWidth; *(pucImage + 2) = lWidth >> 8; *(pucImage + 3) = lHeight; *(pucImage + 4) = lHeight >> 8;
Similarly, when testing the draw routines in offscr1bpp.c, reading the width caused alignment traps. Using the GrImageWidthGet macro from grlib.h to read the width fixed those problems. I now have the 1BPP draw routines working as expected.
The larger question as to why these bugs exist still bothers me. A local FAE visited me yesterday, and speculated that this code was originally developed for a processor which does not have alignment issues, and was not actually tested on Sitara processors.
It would be nice to get this confirmed.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.