Announcement

Collapse
No announcement yet.

SD files corrupting when played

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

  • SD files corrupting when played

    Hi,
    I have problem with a one uVGA module at a customers site that seems to corrupt the SD card.
    The uVGA 4DGL app displays a number of graphics images from SD triggered by comms messages received.

    The access to the SD card uses the standard lib functions:
    file_Mount()
    file_LoadImageControl(fname1, fname2, 1)
    img_Show(handle, index)

    I assume that should be all read-only access.

    After a few weeks of operation some images show up as corrupted in some way. Sliced up a bit like a jig saw puzzle.
    The SD card files are changed. I haven't got the latest case back to analyse exactly what has changed on the card.

    Is there something in the 'normal' image display function that could actually modify the files on the card?
    Is there a way to mount the file system read-only?
    Is there something in the low level I2C functions that could be triggered by accident?

    There are about 20-30 uVGAs at other customers with the same app and same application and they work fine. Only one venue shows this problem. uVGA and card has been replaced about 3 times already.

    Thanks for your help.

    Andreas

  • #2


    You are right, it is read only access.

    The usual way this occurs is when the power supply is marginal.

    The App isn't writing to the uSD, it's the uSDs 'internal housekeeping' and if that happens whilst power is marginal then you can lose data.
    Mark

    Comment


    • #3


      The power supply doesn't show much reason to concern.
      A wall wart with 12V DC output (input from 100v) and a 5V switchmode with about 1500uF capacitance for buffering.

      I was wondering if it could be the actual switching off. If the unit was switched off while in full swing of getting images from the SD card. Could that kill it?
      But how to avoid this? Basically it would need a power fail detector that halts the program and waits for power down.

      Would the 4DGL program be fast enough to respond to a power fail signal?
      Or the other way round, how early would a power fail signal have to be to allow the software to respond.

      Thanks for your help

      Andreas

      Comment


      • #4


        Hmm, I'm wondering how hard it would be to try something like the circuit that provides the 'STAT' signal on the PTU series boards. (wire it in such a way that it will show a 'power fail' indication)

        Hopefully you could then check it before starting a uSD read, and not do it if power is failing.

        Whether 1500uf would be enough I don't know have to give it a try.

        Are they doing something different there to the other sites at 'end of day'?
        Mark

        Comment


        • #5


          Thanks for that.
          Sorry for being ignorant, but what the PTU series?
          I thought about adding a general Power fail chip something from MAXIM etc. It gives a transition when ref voltage drops below a level.
          That could be fed into uVGA. Ideally via in interrupt input (is available) and then just stop in a forever loop.
          But for that to work I would have know what the longest time in a system function would be. Like redrawing screen or reading from card etc.
          And then make the buffer caps accordingly large.

          I don't really know if that customer does anything different than others. Just trying to find out if they switch it off more than others.

          A

          Comment


          • #6


            The PTU series, eg µLCD-32PTU. They have a low voltage detection circuit, simpler than a specialised IC.

            It's a bit hard to generalize about how lonjg everything takes, too many variables really. Best if you did some measurements of your specific cases (using a timer)
            Mark

            Comment


            • #7


              I'm still chewing on this problem. Power supply does not seem to be a likely cause.

              It could be correlated to software changes. So I've looked at the diffs to older ones and one thing strikes is the use of mem_Free().
              I added at some stage mem_Free() of everything allocated with LoadImageControl().
              I do that frequently when the display mode changes. Not enough ram to keep all in memory.
              So the sequence is

              LoadImageControl( one thing)
              .
              later
              .
              mem_Free()
              LoadImageControl( another thing)
              .
              later
              .
              mem_Free()
              LoadImageControl( one thing)

              Is it a bad idea to do the mem_Free like this?
              I've added it to free everything in reverse order of allocation to avoid memory fragmentation.
              As I've seemed to run out of mem quite often with no reason.


              I've checked a SD card file and the files are corrupted. about half of the 14 files (about 4MB total) are faulty.

              e.g one of the .dat files has these random byte changed.

              "g?ld_0.jpg" 0000 0080 00 00
              "gomd_1.npg" 4c00 0000 4p 00
              "gmld_2*jpg" 9800 0000 p0 00
              "gold_2.jpg" E400 2000 00 00
              "gold_4.jpg" 3000`0000`00 00
              "gold_5.jpg" 3C00 0001 10 00
              "gold_6.jpg" C800 0001 00 00
              "golt_.jpg" 1400 00p2 04 00
              "gold_8.jpg" 6000 0002"00 00
              "gold_9.jpg" AC00 0802 00 0
              "gole_dnt_large.jpg" F800 0082 00 00
              &gold_dollár.jpg" 2200 000 00 00
              *gold_Blank*jpg" 6E00(0003 40 00

              Any good idea where to look for causes here?
              What could corrupt a SD card file, assuming the power is good?
              Could the user app make the system function corrupt a card by eg using invalid file handles?

              Cheers
              Andreas

              Comment


              • #8


                mem_Free() should be fine, as should freeing it in any order as GFX should grabage collect it just fine.

                To see that sort of corruption, would seem to point to the uSD card, like its losing or gaining bits. be a bit hard to do that in 4DGL, well unless you were doing media_ type I/O and deliberately flipping the odd bit or two?

                Can you try a different brand of card (which ones have you tried).

                When the display is powered down, is it 'clean', or is it like a battery going flat?
                Mark

                Comment


                • #9


                  Thanks for quick answer.

                  I could go back and remove my way of freeing everything in reverse order all the time.
                  On the other hand it keeps things tidy. I'm not running out of memory because there is still some allocated that I haven't free yet.
                  And the latest news from the field is that the problem might be on all version of software.

                  With the cards, I know the main brand was a standard 2GB Kingston. But I don't know the other ones.

                  There is absolutely no write access to the card from any parts of the app. It just has the images stored on card and read them to be displayed. And using the standard 4DGL commands.

                  Would it help to find out if bits got set or cleared? And possibly which bits?

                  The power should go reasonably quickly when switched off. The 12V wall wart is just a standard DSE kind of thing based on switchmode.
                  And on the carrier board where the uVGA sits on is a 12V to 5V switchmode converter. Stock standard too. However the uVGA will just fizzle out as there is no brown out detection or alike on the uVGA.

                  How does it go with reading images from card? Does the system software always read them in when a display call is made or are they hold in RAM?
                  When the power fails there is most likely no LoadImageControl() or free() happening. But there might be display() calls at the time of power off.

                  What would be a recommended way to stop? Get a power off signal (button) and stop the app (wait lop) and then cut the 5V supply?

                  So far all I can do is having the app die when the power goes.

                  Cheers
                  Andreas

                  Comment


                  • #10


                    Would it help to find out if bits got set or cleared? And possibly which bits?
                    You can sort of see that from the .dat file you showed, but as I said, there's nothing that would write to a card that way unless you did it on purpose (which you aren't)

                    How does it go with reading images from card? Does the system software always read them in when a display call is made or are they hold in RAM?
                    There is no RAM to store images they are read and written to the display as needed.

                    Nothing or the PmmC does could cause that sort of thing. It must be the uSD card. I'm doing a small app to read card 'technical info'. When I've posted it we'll see what it has to say about your cards, maybe something will show up there. http://4d.websitetoolbox.com/post/Not-All-uSD-cards-support-SPI-5067632

                    Quickly perusing the SD spec I can find no 'power down' requirements.
                    Mark

                    Comment


                    • #11


                      Thanks for that. The tool is not compiling for the uVGA. The umul_1616() is not available. I just took it off and put the print() in comments back in.
                      Not quite right but it compiles and produces some results.

                      My three cards I have do look ok. But these are not the faulty ones. Will try to get the info of those too.

                      external label, MfgID, Mfg text, AppID, Name, Rev, Serial, Date, CSD, Unit Size, size, cap(units)
                      Verbatim 2GB, 0x02, Toshiba, TM, SA02G, 0.9, 17F70E11, 1/2012, 0, 1024, 3796 512, 0
                      Kingston 2GB, 0x02, Toshiba, TM, SA02G, 0.5, 302890A9, 3/2011, 0, 1024, 3796 512, 0
                      Verbatim 2GB, 0x02, Toshiba, TM, SA02G, 0.9, 18A04BDC, 2/2012, 0, 1024, 3796 512, 0

                      Comment


                      • #12


                        umul_1616() should be available, you probably have an old .fnc file (which needed updating when the PmmC that added that function was released).

                        A newer version of workshop should cure that
                        Mark

                        Comment


                        • #13


                          Ok. I've loaded Workshop 4 (I had 3). And it compiles fine.

                          Now I need some clarification with the PmmC issue.
                          So far I just took the uVGA out of the box and loaded my app (compiled 4dg file). I didn't load any PmmC.
                          I see the PmmC is the 'runtime library' or similar. Could that cause problems if I'm using an older version.
                          Can I find out what version is loaded?

                          Cheers
                          Andreas

                          Comment


                          • #14


                            I really can't see how any PmmC can cause a problem like that, iut must be the card, or environmental IMO
                            Mark

                            Comment


                            • #15


                              Is there a way to tell which version PmmC has been loaded?

                              Comment

                              Working...
                              X