From The SDCARD Spec (the non simplified old one V1.9 after that they only published simplified specs wich left out timing information and writeprotection information:
"22.214.171.124. Write Protection
Two-card level write protection options are available: permanent and temporary. Both can be set using the PROGRAM_CSD command (see below). The permanent write protect bit, once set, cannot be cleared. This feature is implemented in the SD Card controller firmware and not with a physical OTP cell. "
So in theory you can permanently write protect a SDCARD and so render it useless for future use. But for this to happen the Linux SDCARD Driver would have to send a PROGRAM_CSD command (CMD27) to the SDCARD with the appropriate writeprotection bits set. I cannot imagine the SDCARD driver even sending a PROGRAM_CSD command. (for normal operation you'd only read it during initialisation to get info about the card). It might be bossible for low power situations that a voltage drob might flip a Bit to zero on the bus i suppose, but the original command must be almost identical to the resulting PROGRAM_CSD command for that to occur.
The CSD register of the SDCARD is a 128 Bit data structure (Bit 127 to Bit 0) which holds the permanent write protection bit at position 13 (one time programmable) and the
temporary write protection bit at position 12 (programmable several times)
It can be read with the SEND_CSD command (CMD 9).
These Bits affect the whole card.
optionally there are also the commands
These commands aply to writegroups on the SDCARD but not all SDCARDS implement those commands.
Either way if the card is not permanently write protected it can be erased using a force erase, wich will work even if the card was locked with a password like in some Windows Phones which could render cards useless for other devices. So to recover your SDCARDS you'll want to do a force erase.
To do a force erase you have to send a CMD 42 (while the card is in transfer state) to the card with Bit_3 set to 1 and Bit_2, Bit_1 and Bit_0 set to 0.
This shold remove all temporary write protection bits from the CSD register and Group Write protections from the commands 28-30.
The tricky bit will be sending those commands to the card. You could try to connect the card via SPI Bus and to talk to the card via spi protocol. If you search the forums someone already wrote a SDCARD driver for the SPI bus for a second SDCARD slot on the RPi i think. It might be worth looking at that. You'd have to initialize the card and get it into transfer state before you could send the CMD 42. I suppose some programming with the progamming language of your choice will be required to do so. Luckily the RPi does have a SPI interface on the GPIO Header that you could use since the SDCARD slot will have to hold the OS you'll be using - your chance to learn something about the SDCARD standard, and learning / teaching is what this device is all about, right?
So if you want to investigate, first I'd check via CMD_9 (SEND_CSD) wether your card is really permanently write protected, wich I doubt very much.
(If it really is, it might be interesting to see from where it got those commands but for that you'd probably want to attach some SPI protocoll analyzer to the bus or some digital Oscilloscope with SPI decoding / triggering functionallity. And yes devices like that are not cheap, if you're lucky you have access at them at work i suppose...)
And if those faulty commands result from insuficient powersupply then a solution might be to use a good quality Powered USB Hub wich does not draw power from the RPi, or to use a usb cable with the 5V power connection cut to connect the powered hub. You might also solve the problem by modding your RPi (replace the USB Polyfuses with 1/2 Ohm Resistors and place a large Capacity behind them to provide energy for the USB device when hotplugging). I think this is also extensively covered in other threads on the forum.
So if you are curious wether you can recover your SDCARDs I'd reccomend you to have a look at these documents here:
http://www.senita.de/downloads/SD-Card- ... rdv1.9.pdf
https://www.sdcard.org/downloads/pls/si ... 100518.pdf
The first one is the old spec before there were SDHC cards, but with a lot of information that has been left out in later simplified versions.
The second one is the new spec, but in simplified form (Full spec can only be obtained by SD Card Association members). It lacks timing information but you can get that from the old doc and it lacks info on some other commands like write protection and security features. On the other hand it documents most of the new commands and datastructures that came with SDHC and SDXC.
So taking those 2 documents together there is all the information you'll ever need to write a SDCARD driver or to interface a your RPi to a SDCARD.
Good luck in investigating