Hot!(__pack_upper_byte char *) not reading properly at address 0x1FFFF

Author
antarm
New Member
  • Total Posts : 27
  • Reward points : 0
  • Joined: 2011/09/21 12:51:12
  • Location: 0
  • Status: offline
2018/08/15 08:03:43 (permalink)
0

(__pack_upper_byte char *) not reading properly at address 0x1FFFF

I am using the graphics library within MLA_v2017_03_06, with XC16 v1.21. I have defined both GFX_CONFIG_FONT_PROG_SPACE_ENABLE and GFX_CONFIG_FONT_PACKED_ENABLE, so that the fonts are packed to use all 24bits of program memory.

If a character bitmap resides in memory across address 0x20000, some of the pixel data is read in corrupt. Within GFX_TextCharRender(), "pParam->pChImage" is used to read character bitmap from flash memory. When using "pParam->pChImage", it appears that the data read from address 0x1FFFF is corrupt. The data before and after 0x1FFFF seems fine.
 
It is read in corrupt for the 'temp = *(pParam->pChImage)++;' line of logic within gfx_primative.c. It is the 'pChImage' pointer to this memory that seems to misread.
 
The program memory itself appears to have the correct (bitmap) data, and I have verified with both the 'program memory' window, and also when doing builtin_tblrd reads. 


relative code snippets... 

#define GFX_CONFIG_FONT_PROG_SPACE_ENABLE 
#define GFX_CONFIG_FONT_PACKED_ENABLE 
#define GFX_CONFIG_IMAGE_PACKED_ENABLE 

#ifdef GFX_CONFIG_FONT_PROG_SPACE_ENABLE 
#ifndef __PIC32MX__ 
#ifndef GFX_CONFIG_FONT_PACKED_ENABLE 
#define GFX_FONT_SPACE __prog__ 
#else 
#define GFX_FONT_SPACE __pack_upper_byte 
#endif 
#else 
#define GFX_FONT_SPACE const 
#endif 
#else 
#define GFX_FONT_SPACE const 
#endif 

GFX_FONT_SPACE uint8_t *pChImage; // pointer to the bitmap of the character
 
#1

8 Replies Related Threads

    antarm
    New Member
    • Total Posts : 27
    • Reward points : 0
    • Joined: 2011/09/21 12:51:12
    • Location: 0
    • Status: offline
    Re: (__pack_upper_byte char *) not reading properly at address 0x1FFFF 2018/08/15 08:08:51 (permalink)
    0
    Also, I am having issues troubleshooting, since (according to microchip docs) you cannot cast a pointer to 24bit flash data, and the watch window cannot properly monitor a (__pack_upper_byte char *)  pointer.
     
    My problem is that in troubleshooting this code, the data at this location changes for different builds, due to the add\removed troubleshooting code. Due to the requirement of the __pack_upper_byte pointer to manage accessing the packed data, and not knowing how to ensure the required struct is placed across 0x1FFFF\0x20000. 


    Is there a way to declare a __pack_upper_byte char array, that is located at a fixed program memory address of 0x1FFF0, and is large enough to go through to address 0x20010? 

    I tried the following, but could not get it to build. 

    GFX_FONT_SPACE char __attribute__(address(0x1FFF0))) dataDebug[64] = 
    { 0,1,2,3,4,5,6,7,8,9, 
    10,11,12,13,14,15,16,17,18,19, 
    20,21,22,23,24,25,26,27,28,29, 
    30,31,32,33,34,35,36,37,38,39, 
    40,41,42,43,44,45,46,47,48,49, 
    50,51,52,53,54,55,56,57,58,59, 
    60,61,62,63 };
    #2
    moser
    Super Member
    • Total Posts : 400
    • Reward points : 0
    • Joined: 2015/06/16 02:53:47
    • Location: Germany
    • Status: offline
    Re: (__pack_upper_byte char *) not reading properly at address 0x1FFFF 2018/08/15 08:56:20 (permalink)
    0
    Your code here has the wrong number of opening brackets after __attribute__.
     
    I can't help you with the rest.
     
    #3
    antarm
    New Member
    • Total Posts : 27
    • Reward points : 0
    • Joined: 2011/09/21 12:51:12
    • Location: 0
    • Status: offline
    Re: (__pack_upper_byte char *) not reading properly at address 0x1FFFF 2018/08/15 08:59:32 (permalink)
    0
    Thanks, I agree with the opening brackets.  it was a typo here on forum, and it is setup as follows in the actual source.
     
    GFX_FONT_SPACE char __attribute__((address(0x1FFF0))) dataDebug[64] 
    #4
    Pusb
    Moderator
    • Total Posts : 101
    • Reward points : 0
    • Joined: 2004/02/09 09:47:27
    • Status: offline
    Re: (__pack_upper_byte char *) not reading properly at address 0x1FFFF 2018/08/23 16:45:19 (permalink)
    0
    why are you declaring an array with GFX_FONT_SPACE manually ?
     
    That is used in the generated outputs by the Graphics Resource Converter only. 
    End application would not use this directly.
     
    Please see gfx\primitive_layer demo as example.
    #5
    Wieschebrock
    Super Member
    • Total Posts : 192
    • Reward points : 0
    • Joined: 2005/01/22 07:57:44
    • Location: Germany
    • Status: offline
    Re: (__pack_upper_byte char *) not reading properly at address 0x1FFFF 2018/08/27 06:08:56 (permalink)
    0
    Use the actual compiler V1.35
    #6
    antarm
    New Member
    • Total Posts : 27
    • Reward points : 0
    • Joined: 2011/09/21 12:51:12
    • Location: 0
    • Status: offline
    Re: (__pack_upper_byte char *) not reading properly at address 0x1FFFF 2018/08/27 09:04:42 (permalink)
    0
    I am trying to resolve a potential bug within gfx source or xc compiler, which does not read packed memory properly, specifically at address 0x1FFFF.
     
    I am using XC16 v1.21, since my main project's source is reliant on microchip's peripheral library, which is not compatible in versions beyond v1.21.  We would need to restructure our main project's source code to be compatible with v1.35, and this is not a trivial task.  I would like to confirm that v1.35 will resolve this issue, prior to converting the source.
     
    For troubleshooting, I am declaring an array with GFX_FONT_SPACE, in an attempt to force the issue under my control.  It gets difficult to troubleshoot, since a GFX_FONT_SPACE* variable is not fully visible within the watch window.  I am trying to setup a project that exhibits the issue in a more controllable form, hopefully making troubleshooting straightforward.  So far, I have been unsuccessful at creating this project, and I am currently waiting for service from microchip.
     
    I am trying to create a 'simple' standalone debug project.  I can then test potential solutions with this debug project, without affecting my main project.  After a solution is identified on my debug project, I can determine how to address it in my main project.  I could use this platform to check if the latest xc16 compiler resolves it, along with other solutions.
     
    #7
    Aussie Susan
    Super Member
    • Total Posts : 3355
    • Reward points : 0
    • Joined: 2008/08/18 22:20:40
    • Location: Melbourne, Australia
    • Status: offline
    Re: (__pack_upper_byte char *) not reading properly at address 0x1FFFF 2018/08/27 19:01:47 (permalink)
    0
    Do you mean "compatible" or "is not bundled with PLIB".
    As far as I know, you can download the PLIB separately and use it with the more recent compilers.
    It is just that PLIB is supposed to be replaced by MCC and so is no longer provided as part of the compiler package.
    Susan
    #8
    Pusb
    Moderator
    • Total Posts : 101
    • Reward points : 0
    • Joined: 2004/02/09 09:47:27
    • Status: offline
    Re: (__pack_upper_byte char *) not reading properly at address 0x1FFFF 2018/09/11 09:40:09 (permalink)
    +1 (1)
    to help conclude this thread, antarm has notified microchip via the ticket support channel that updating to use XC16 v1.35 has helped resolve the corruption issue observed.
    #9
    Jump to:
    © 2018 APG vNext Commercial Version 4.5