• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 680 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TM4C1290NCPDT: Cropped Images after migrating from Stellaris Ware

abraxas2k
Prodigy 235 points
Part Number: TM4C1290NCPDT

Hello,

I migrated my fine running firmware from a Stellaris Board with Graphics Library rev9107 to a Tiva Board with Graphic Lib revision 2.1.3.156.

Now, all my converted images lack of at least one row of pixels on the top of every image.

Was there any change in drawing Canvases? 

One example of my canvases:

const Canvas(g_sBoot_Img, &g_sMenu_Screen, &g_sBoot_Product_Name, 0,
&Crystalfontz_SSD2119,
0, 0, 320, 105,
(CANVAS_STYLE_IMG ),
BOOT_BG_COLOR, MAINFRAME_FILL_COLOR, MAINFRAME_FONT_COLOR_GENERAL, MAINFRAME_FONT_SMALL, 0, img_boot, 0);

The *.h file of the img_boot looks like this:

const unsigned char img_boot[] =
{

IMAGE_FMT_8BPP_UNCOMP,
24, 1,
66, 0,

251,

//* here would be the whole data of the image*/

}

  • 0
    TI__Guru 72500 points
    Which display are you using and how is it interfaced to the TM4C1290NCPDT?
  • 0
    Guru 117855 points

    abraxas2k said:
    all my converted images lack of at least one row of pixels on the top of every image.

    This (quickly) suggests 3 possible, "causes of failure:"

    • The address at which your top row of pixels is stored w/in your MCU is being (somehow) corrupted
    • That "top row, pixel storage address" is NOT being corrupted - but the, "Write to the Lcd" screen (top pixel row(s)) is improper (or not being executed)
    • The loss of, "At least one row of pixels" may signal that added delays are required - either in the:  a) read of the stored pixel info, b) write to the Lcd after reading, or both

    To troubleshoot - does it not make sense to create a "temporary" elementary image - with an easily recognizable, "pixel pattern" - store it - and then execute your code.    You should be able to determine the precise location of your temporary image w/in the MCU - and then by monitoring the Lcd bus - determine "if that easily recognizable, top row data" is being output to the Lcd.    You should also check that the MCU employs the correct address when fetching that (top row(s)) your temporary image.

    The fact that you are able to correctly fetch stored image data (subsequent rows) & then paint the Lcd - (clearly) removes the Lcd & interface from, "likely suspects."   (in NO way is this an Lcd issue...)

  • 0 in reply to cb1_mobile
    Prodigy 235 points
    There are quite a few images, it is very unlikely that all of them are corrupted.
    I cannot say for sure, but I think all images miss only the first row of pixels.

    I will take a look at the functions you mentioned. Maybe there is some problem as I also switched to a more recent CCS (and Compiler).

    @Bob: The display uses SSD2119 RGB Interface. We connect with SPI.
    To be more specific, we are using an updated version of our Stellaris board. Only necessary changes for the Tiva were made.
  • 0 in reply to abraxas2k
    Guru 117855 points

    It is NOT your many images which are corrupted - it is the MCU's ability to, "Fetch from each image's (real) starting address" which is suspect.    Most often such errors will reveal a consistency (your pointer to the starting address of your image(s)) has been corrupted and/or incorrectly calculated.

    I've suggested a powerful means to quickly/easily determine which of the 3 "most likely faults" impact your effort.     (the other most likely fault is a corrupted LCD pointer as you initiate the "draw to screen" of each image.)    Such could well point to a delay requirement - which I earlier listed...  

    Following the test method previously provided proves the fastest/easiest means to identify & correct your issue...

    I would wager a very tall stack of Vegas chips that the LCD is completely blameless - subsequent pixel rows fill nicely - do they not?    That clearly removes the Lcd from suspect list...

  • 0 in reply to cb1_mobile
    Prodigy 235 points

    The LCD was never a suspect. I know the display works as it is working fine with my previous firmware. Also, all texts, boxes, etc are drawn nicely. 

    Thats why I suspect there is something going on (or a change I am not aware of) in the GrLib. 

  • 0 in reply to abraxas2k
    Guru 117855 points

    Another here made mention of the Lcd - I "knew" that the Lcd was no factor.

    Twice now there's been no mention of your use/interest in the troubleshooting method I've outlined in your behalf.     I can do no more while that method sits idle...

  • 0 in reply to cb1_mobile
    TI__Guru 72500 points
    Perhaps the behavior you are seeing is because a bug was fixed in version 2.1.0 in February of 2014. See section 5.5.2 on page 36 of:
    www.ti.com/.../spmu299e.pdf
    You may need to undo a workaround that was done when using a previous version of the driver.
  • 0 in reply to Bob Crosby
    Guru 117855 points
    I'm not seeing any behavior - that's confined to the O.P. - I'm humble outsider w/(some) knowledge of Lcds.
    It is of course "interesting" that a, "bug fix" may have caused the O.P.'s recently reported dificulty. It is in all probability a pointer error - I've described "find/fix" tactics in detail...