SAM V71 : MMC hangs for a long time on issuing a stop transfer command - driver or hardware issue?

Go To Last Post
2 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've been benchmarking a memory card for something I'm working on and the idea is that I want to start a write, do some things since DMA is taking care of the transfers then come back and do another write or read, etc...

 

Using the drive in ASF 3.32, here is the test :  

 

err = sd_mmc_start_write_blocks(&AudioFirstSegment[0], rx_local_block_write_count);
                m = 0; //Just for testing...
                while(! ((REG_HSMCI_SR & HSMCI_SR_XFRDONE) && (REG_HSMCI_SR & HSMCI_SR_NOTBUSY)) ){
                    m++; //see how many counts before the transfer is done...
                    };

 

To write, stopwatch says this takes about 725 uS, and counter m = 0x1f50 give or take a few cycles before XFR_DONE and NOTBUSY are back to high. 8 blocks of 512 bytes written in that time, great, meets my application requirements. I would think the transfer was complete, right? The lines are back to high, the operation is done. My idea was do the init and write, do the other things I need to do and prior to the next card related operation poll the XFRDONE and NOTBUSY bits (they should be synchronous according to the datasheet, but I put both in as a safeguard) which should tell me, sure - go ahead and do your next thing.

 

Then I go to read what I wrote, and it won't initialize... so I add in the 

 

err = sd_mmc_wait_end_of_write_blocks(false);

 

command which properly releases the card and allows the read a full compare and , match of the two buffers. It also doesn't matter whether I use true or false - the logic will still always hit and evaluate what I'm going to show...

 

The problem is this - even though the write is done, the "wait" function takes 2.8 mS and 99% of those cycles come from the evaluation of 

        if (!driver_adtc_stop(SDMMC_CMD12_STOP_TRANSMISSION, 0)) {
            sd_mmc_deselect_slot();
            return SD_MMC_ERR_COMM;
        }

 

Is that 2.8 mS inherent to the card/standard/protocol - because I can't find anything that says it should hang that long? Seems to be an issue in the driver, but would love to hear otherwise and if anyone can think of a workaround because what's the point of transferring this data on DMA and then having to sit and wait endlessly for this function to run to ensure it's transferred, especially when polling the XFER and NOTBUSY bits should be a sufficient indicator that the transfer is done? 

 

As a note, the sd_mmc_wait_end_of_read_blocks only takes around 7 uS if I have polled the status lines as displayed in the code below. 

 

                err = sd_mmc_init_read_blocks(slot, rx_block_current_write, rx_local_block_write_count);
                err = sd_mmc_start_read_blocks(&AudioLastSegment[0], rx_local_block_write_count);
                m = 0; //Just for testing...
                while(! ((REG_HSMCI_SR & HSMCI_SR_XFRDONE) && (REG_HSMCI_SR & HSMCI_SR_NOTBUSY)) ){
                    m++; //see how many counts before the transfer is done...
                };
                err = sd_mmc_wait_end_of_read_blocks(false); 

 

Removing the polling and going straight to the sd_mmc_wait_end_of_read function, totals at about 870 uS which is inline with the original time mark. It's calling the same driver_atdc command, so I don't understand the difference in time between the two things...

 

 

 

 

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Upgrading cards improved performance.

Not using EDBG at the same time improves performance significantly, like 10 fold. Unfortunately, there are lots of problems with debugging via a J-link Plus rather than EDBG, like the EDBG pulls the I2C shared with the Codec I2C on the V71-XULT permanently low so that you have to constantly unplug and replug the board in to release them. Unreal.