• Not Answered

grlib causes Undefined Instruction trap

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[2][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? 

Gerry Belanger


2 Replies

  • 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=4
    unsigned 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)];
    #else
    unsigned char g_pucBuffer[GrOffScreen24BPPSize(LCD_WIDTH, LCD_HEIGHT, PIXEL_24_BPP_UNPACKED)] __attribute__ ((aligned (4)));
    #endif

    Regards

    Max

  • 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.

    GerryB