2 Replies Latest reply on Nov 21, 2014 8:46 AM by pekac_285506

    SIB read-modify-write fails



      I'm currently facing an issue with my access to the eMMC memory. To have a byte write API in upper levels, I implement an eMMC block read-modify-write in the FX3 firmware. Initially, things looked good, however, when I'm testing very high byte addresses (i.e. the ones in the highest few blocks of the big user partition), I find out that it does not work correctly.


      Stepping through the whole code with the debugger, everything always worked properly (not a very nice effect, when you try to track down an error). With this result, I started to insert sleeps into the code to make out which wait actually has influence on the issue, and found out that its the one right before writing back the block(s). It's the [CyU3PThreadSleep(1)] statement in the appended code extract.


      Any hint, what kind of effect this is? Actually, I'm using debug build configuration, so no "optimizing away" things should happen. Is there any restrictions in accessing the same eMMC block (read-modify-write). I assumed that waiting for read buffer, waiting for completion (DMA methods) should be enough. Is there some additional SIB/eMMC busy flag I'm not aware of?

        • 1. Re: SIB read-modify-write fails





          I have never seen such issues before. I am not sure if I have ever tested the same scenario as well. Can you please let us know what you describe as " it does not work correctly" situation? Does WriteBlock function never return, or any error code? Or do you see different data when you do read following the write?







          • 2. Re: SIB read-modify-write fails



            Actually there was no error message or similar, all API methods conclude successfully, FXY3 works without exceptions. I just observe wrong data in the concerned memory page when reading it out later. What I observe is that my bytes just have not been written to the page or worse, the whole page has been set to 0x00 when writing back.


            If there is no restriction in read-modify-write access of the same eMMC block, I think it could be some threading issue. Is there a way to make sure a DMA (which runs in a different thread) did really completely terminate its task (besides waiting for CyU3PDmaChannelWaitForRecvBuffer, CyU3PDmaChannelWaitForCompletion indefinitely, i.e. CYU3P_WAIT_FOREVER)?


            The fact that it works well with the waiting period and in case I step through in the debugger tells me it must be something in that direction.