Announcement

Collapse
No announcement yet.

Address Trap - what does it mean?

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

  • Address Trap - what does it mean?

    We've used dozens of uLCD70-DT's.
    Over the past couple weeks we've had some displays "crash" and show an ADDRESS TRAP screen (see attached.. sorry its upside down).
    This is a Rev 2.2, being commanded by an Arduino via the serial API.

    What causes this?
    Attached Files
    Last edited by Dave Chambers; 7th December 2017, 07:12 AM.

  • #2
    The easiest way to do this is with totally invalid parameters to, say, a gfx_Set() Command.

    Hopefully you will be able to work out the last command issued from the Arduino and check its parameters.
    Mark

    Comment


    • #3
      Thanks, I can trace my commands & I should be able to figure out the offending command. I'll let you know.

      I'll also check the display's Model, Version, and PmmC versions to see if anything is different there.

      Comment


      • #4
        Info from investigation:

        Quick summary: img_Show() works in PmmC v512, but crashes in v263 (when everything else is identical)

        But, an earlier call to show this same image succeeds, so that suggests that it's a sequence thing, meaning that some earlier commands in my sequence made the display unhappy and it's just coincidence that img_Show() is the thing that finally pushes it over the edge.



        More detail:

        I have two displays, one that works and one that doesn't.

        For both I queried sys_GetModel, sys_GetVersion, and sys_GetPmmC
        For both, the model is "uLCD-70DT" and version is 258.

        However the unit that works has PmmC=512 and the one that DOESN'T work has PmmC=263

        I then, on the unit with PmmC 263, traced the failure to the img_Show command.
        (Again, this command with this image has succeeded earlier in my program)


        To verify that the image is accessible I queried the image's parameters (aka Image Words), and that works fine:
        (note: the index of the image in my GCI is 1)
        img_GetWord[FE84] 2DAA 0001 0002 ACK 01-04 260 // IMAGE_XPOS = 260
        img_GetWord[FE84] 2DAA 0001 0003 ACK 00-10 16 // IMAGE_YPOS = 16
        img_GetWord[FE84] 2DAA 0001 0004 ACK 01-17 279 // IMAGE_WIDTH = 279
        img_GetWord[FE84] 2DAA 0001 0005 ACK 00-3A 58 // IMAGE_HEIGHT = 58
        img_GetWord[FE84] 2DAA 0001 0006 ACK 80-18 32792 // IMAGE_FLAGS = 0x8018 = ENABLED, COLOUR16, (bits 0-3 reserved)
        img_GetWord[FE84] 2DAA 0001 0007 ACK 00-00 0 // IMAGE_DELAY = 0
        img_GetWord[FE84] 2DAA 0001 0008 ACK 00-00 0 // IMAGE_FRAMES = 0
        img_GetWord[FE84] 2DAA 0001 0009 ACK 00-00 0 // IMAGE_INDEX = 0

        And I can successfully set the image's position (x=260, y=16) prior to drawing it:
        img_SetPosition[FE8A] 2DAA 0001 0104 0010 ACK 00-01 1
        (It's coincidental that I'm setting the position to the exact same values as the image's XPOS and YPOS Words are set to)

        But img_Show craps out:
        img_Show[FE83] 2DAA 0001 timeout Serial 4D Library reports error Timeout
        (and the "ADDRESS TRAP" message shows onscreen)

        So it would seem that something has changed between PmmC v263 and v512 which allows img_Show to work in the later version yet fail in the earlier version. Certainly, many things have changed between those versions


        I'm **REALLY** not wanting to have to update the PmmC's for all my units in the field.
        Any ideas for additional stuff I could try to either narrow down the exact cause and/or create a workaround would be GREATLY appreciated.

        Thanks,
        -Dave

        Comment


        • #5
          More:
          The screen where this happens has some other images & text.
          I had been drawing this image last, after all other images & text.
          I found that if I draw the image FIRST, then it doesn't crash, even with the other stuff being drawn after this image.

          Comment


          • #6
            So the PmmC versions appear to be 1.7 and 2.0 (gleaned by using the hex values)

            The release notes can be seen here http://www.4dsystems.com.au/download...leaseNotes.txt (just click on the appropriate button in Workshop under File, Options, Updates)

            Although not a direct 'hit', the only related issue seems to be 2] in the 2.0 PmmC. Perhaps you can ensure the files on uSD are not fragmented to see if that could be the issue (Chkdsk *.* will show fragmented files)
            Mark

            Comment


            • Dave Chambers
              Dave Chambers commented
              Editing a comment
              Any chance I could get ahold of the 1.7 PmmC? I need it for testing updates, so after I push the 2.0 I can revert to 1.7 and re-test, then re-update.

          • #7

            Doesn't look like there's any fragmentation

            F:\>chkdsk *.*
            The type of the file system is FAT.
            The volume is in use by another process. Chkdsk
            might report errors when no corruption is present.
            Volume SN477 created 11/27/2017 12:51 PM
            Volume Serial Number is 1252-864B
            Windows is verifying files and folders...
            File and folder verification is complete.

            Windows has scanned the file system and found no problems.
            No further action is required.

            3,960,733,696 bytes total disk space.
            65,536 bytes in 1 hidden files.
            32,112,640 bytes in 30 files.
            3,928,555,520 bytes available on disk.

            65,536 bytes in each allocation unit.
            60,436 total allocation units on disk.
            59,945 allocation units available on disk.
            All specified files are contiguous.

            Comment


            • #8
              I earlier wrote: I found that if [on the 1.7 PmmC] I draw the image FIRST, then it doesn't crash
              But then I found that it does crash on a different unit with the 1.7.
              Thus my trick of rearranging calls was just a coincidence (as I feared it might be).

              So I think my only real solution will be to update the PmmC. This means my device must do this in the field, ie. no connecting the programming cable and running a Windows program.

              4D had earlier supplied me with the serial protocol for pushing a 4XE (reset, enter bootloader by sending "4dgl", display responds with 'D' if it's a Diablo, etc).
              Could you provide the low-level serial protocol for pushing a new PmmC? Because I'm in an embedded environment I (obviously) can't use the .NET libs and must do it "manually" across the serial port.

              Thanks!
              -Dave

              Comment


              • #9
                Please use the Contact form from the website and mention your current NDA.

                The samples do not use any .NET libs, actually no 4D software uses them.

                I have set you the R17 PmmC
                Mark

                Comment


                • #10
                  Thanks!

                  I received the 1.7 PmmC and submitted support ticket 4DTB8706231

                  -Dave

                  Comment

                  Working...
                  X