Announcement

Collapse
No announcement yet.

Strange display chaos when adding a single line of code (some internal compiler bug?)

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Strange display chaos when adding a single line of code (some internal compiler bug?)

    Hello, this is my first time here, so please let me know if I'm posting something incorrectly...
    I was doing some code on the DESIGNER. No graphics over the SD card, just plain sequential code.
    Adding one single extra line to it, causes the display to go completely berzerk... Commenting ANY other line that already worked fine, seems to make it work OK again.
    Somehow, the compiler goes avry when adding more code to the main file. ANd from there on, the display remains chaotic and with repeating strings, etc.
    Could someone of the administrators check this apparently obviously identified bug. please? I cannot continue like this.
    Some data that could help:
    - No Errors, code size = 2096 bytes out of 32750 total
    - Initial RAM size = 200 bytes out of 32768 total
    - Program will run from ram so total initial RAM size = 2296 bytes out of 32768 total
    - downloading to RAM or FLASH, doesn't make any difference
    - Gen4-uLCD-24DT
    - Workshop4 IDE Version 4.5.0.17
    - Screenshots attached
    - Project attached

    Chaos when adding code: OK when commenting that code:
    Click image for larger version  Name:	CHAOS.JPG Views:	1 Size:	389.9 KB ID:	63020 Click image for larger version  Name:	OK.JPG Views:	1 Size:	361.5 KB ID:	63021

    This clearly seems to be a COMPILER problem...

    THanks in advance,
    Pedro Kulzer @KulzerTEC
    Last edited by pkulzer; 24th April 2018, 09:46 AM.

  • #2
    The first pass of the compiler tries to reduce strings to single occurrences by scanning the 'ROM' area of code for an existing occurrence and, if found, simply sets the string address to the found 'duplicate' and continuing.
    Unfortunately there are address constants in the 'ROM' area that change in subsequent passes and this means that sometimes (Very rarely, you are the first to report this) these 'duplicate' strings aren't.
    Somehow your "MAX=1234" must be matching to a changing area of this 'ROM' space.

    Anyway there is a simple workaround. Place
    Code:
    #DATA
        byte kkkk "MAX=1234"
    #END
    Before your main function. this will cause your string to be placed at the start of the 'ROM' area and thus be found first by the scanning code.
    Mark

    Comment


    • #3
      Thanks for the workaround, but it doesn't work well... It works in this down-stripped code I sent you, but when I try to use the exact same thing for the complete code, it now even trashed the display IF I'm using the "#DATA" construct... If I comment out that "#DATA" block it works fine, etc... I can't go forward like this... Is there any chance of bugfixing this in the compiler anytime soon? I'm testing your 4D displays for a future real-world testing application but I'm now stuck in the middle with this compiler bug.

      Thanks,
      Pedro Kulzer

      Comment


      • #4
        I tried to put all strings into that "#DATA" block but now nothing is corectly displayed, even a worse mess. Every string in that block is now shown Nx... Can't continue... PLease advise.

        Is there a way to turn off this ind of optimization your compiler does, so that I may continue working without these problems? That'd be great!
        Last edited by pkulzer; 25th April 2018, 09:28 AM.

        Comment


        • #5
          Please send you r complete code to mark at 4dsystems dot com dot au.

          We need to figure out exactly what the problem is in your case.
          Mark

          Comment


          • #6
            Hello Mark, as by your advice, I sent you the complete source-code for you to check.
            Thanks in advance!
            Pedro Kulzer

            Comment

            Working...
            X