Problems reading the Delkin Micro SD 16 GB using SPI
I think you should have noticed the pattern:

fe 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 00 01 02 03 ...

shifting this sequence two bits right you get

ff 80 00 40 80 c1 01 41 81 ...

So exactly the sequence you have. You have added two spare bits into the stream, and bytes got misaligned. Why? Without exact diagrams showing the clock it is not possible to say. Most probably you have issues with clock or data synchronization to it.

This misalignment may happen in either write or read - so it may appear that you write wrong sequence because your write command has bytes misaligned, and then read that wrong sequence back (of course), or it could be purely read command issue. The conclusion that you must check what SD-card has actually written to it - using another functioning device (e.g. PC dumping you card to the file and checking the image) - before going into debugging read or write command execution.

Edit: looking to the scope diagrams I see/recommend the following:


change clock polarity when idle to low. Currently it is high. Check here. In other words - use SPI mode 0;
before command starts (before you put first 0 onto MOSI line) perform 8 spare clock cycles with CS low. Ideally you do the same at the end of the command - put 8 spare clocks with CS low when command completes, and another 8 spare clocks with CS high;
not sure I understand second pic - you send FFs as command to the card? And seems card continuously reports 0x05 (invalid command).


Edit 2:


  The second oscilloscope image, immediately follows the first oscilloscope image.


Be very cautious when deselecting the card - your images show that you issue command to the card, deselect it raising CS high, and then reselect it continuosuly sending 0xFFs to the card. Seems card does not understand that, and sends 0x28s back, which are actually 0x05 - "invalid command" R1 response shifted. There're only specific circumstances when you may deselect the card, it is explained in simplified SD specification, and follows very specific protocol:


  When the card is signaling busy, the host may deselect it (by raising the CS) at any time. The card will release the DataOut line one clock after the CS going high. To check if the card is still busy it needs to be reselected by asserting (set to low) the CS signal. The card will resume busy signal (pulling DataOut low) one clock after the falling edge of CS.


Regarding my second comment


  Also, your comment 2, is it required for all the commands? Currently, I have only applied your suggestion to Read Command.


Spare cycles, while will take some time, will ensure card has properly completed/cancelled the previous operation, and gets ready for next one. So I recommend you to implement it for all commands if possible.