SD Card on Fire

[BeebMaster]

Well, nearly...if I'd left the room and come back a few minutes later I may well have returned to a roomful of burnt cinders. I count this as a very lucky escape.

I just set up a new file server partition on a Pi 1MHz SCSI card...all fine...started the file server...typed *MOUNT 3 and instead of getting the Command: prompt, I just got a * prompt...pressed BREAK and ADFS is reading from floppy. Nothing could get the hard drive back, so I switched off the Pi to test the card in the computer and nearly burnt my fingers bringing it out. It was very hot indeed. I put it in a micro SD card reader slot and nothing happens. Dmesg doesn't even acknowledge it.

In the reader it doesn't get hot, but if I put it back in the Pi Zero (even with nothing else connected to the Pi Zero except power) no lights at all come on and the card heats up in about 5 seconds.

Different card in same Pi OK, same Pi in different location (Tube instead of 1MHz bus) (with different card) OK. Same card in different Pi overheats, so this card has been killed.

How could that happen? And shouldn't there be some sort of overheating failsafe? I mean, it's 2020, this isn't Barnes Wallis in 1943, let's drop a megaton bomb in a swimming pool and see if we can run away fast enough when the explosion starts...

It was a Kingston card. Again.

[Ramtop]

Ouch, lucky escape indeed!

SD cards have little capacitors in them which can sometimes fail as a dead short, and if the host device doesn't have current limiting on the power rail then the cap basically becomes a small heating element.

[BeebMaster]

Of course the side-splitting irony of all this is that I made this Econet partition on the SD card to start rebuilding my Econet file server which suddenly blanked itself in 2013...

[1024MAK]

Are you now calling this SD card, a ‘fire stick’

Mark

[Kazzie]

Maybe you'd better check your printer port too, just in case?

[BeebMaster]

Mmm yes, all very amusing, thank you. Is any data recoverable on this card now? And can I get my money back!!??

[1024MAK]

If you still have your receipt and you have not had it long, take it back and tell the shop that you don’t consider that it was of satisfactory quality, and therefore you expect them to refund you in full. If they get funny with you, tell them that the relevant law is the Consumer Rights Act.

For more details see here.

Mark

[Diminished]

A decade ago, bunnie had some interesting things to say about the reliability of SD cards -- and Kingston ones in particular.

[BeebMaster]

If you still have your receipt and you have not had it long, take it back and tell the shop that you don’t consider that it was of satisfactory quality, and therefore you expect them to refund you in full. If they get funny with you, tell them that the relevant law is the Consumer Rights Act.

For more details see here.

Mark

I was reading that exact link only a few days ago, in relation to something completely Holy Grail Brian Meaning of Different.

But I can't remember exactly where or when I got what, I just usually open the envelope and then stash the new arrivals, neatly arranged in ascending capacity order, in the drawer for future use.

[BeebMaster]

A decade ago, bunnie had some interesting things to say about the reliability of SD cards -- and Kingston ones in particular.

This is very interesting, and confirms some of my own findings about markings on Kingston cards I've posted about elsewhere roundabouts. I've stopped buying Kingston cards as a result of quite a few problems, especially with micro SD cards (some user error, I admit, but some certainly manufacturer defect as well). Perhaps it's time for me to confront the Rt Hon Lord Kingston of Nandgate and see what he has to say for himself!

[BeebMaster]

I'd like to read the "CID" on as many of these cards as possible but it seems I can't do it from a USB card reader.

Pi's OS card is OK, but not a card in the reader:

Code: Select all

pi@raspberrypi:~ $ cat /sys/block/mmcblk0/device/cid
1b534d4242315154302b5f5363012b00
pi@raspberrypi:~ $ cat /sys/block/sde/device/cid    
cat: /sys/block/sde/device/cid: No such file or directory

Maybe I'll have to install some minimal Linux shell on each card and boot from the card...seems a bit overkill though.

[Coeus]

I've had a couple of micro SD cards heat up to very uncomfortable temperatures whilst not responding to the PC. I am not sure if they were branded as Kingston, though.

The bunny article is interesting. Since it was written it looks like Samsung have started marketing cards under their own name. I wonder if this is a significant business for them or a case of setting up fab for flash memory for inclusion in mobile phones and using spare capacity for SD cards. Do we know of any others making the flash chips: Sandisk/Toshiba and Samsung is a pretty narrow choice.

[Diminished]

Rt Hon Lord Kingston of Nandgate

Not sure if it would be worth the time and effort to hook the SD cards up to some raspi GPIOs and get the various IDs out that way. Irritatingly, I have microcontroller-based hardware right here that will print that information out on card insertion.

And yeah, bunnie's an interesting guy.

[BeebMaster]

That's what I'm calling this scandal - Nandgate! And I am Deep Wrote!

Something I read suggested that laptop built-in card reader would do it, but it doesn't. It seems that the device has to appear as an "mmblk" device not "sd" to work.

I wonder if I could read it from Pi connected to 1MHz bus or Tube. Probably not.

[sweh]

I'd like to read the "CID" on as many of these cards as possible but it seems I can't do it from a USB card reader.

Pi's OS card is OK, but not a card in the reader:

USB card readers present to the OS as a "USB Mass Storage" device. These devices don't have a call to expose the CID, so the OS can't tell you what it is.

The Pi internal slot presents as an "MMC device" and that does expose the CID, and so the kernel can tell you.

Maybe I'll have to install some minimal Linux shell on each card and boot from the card...seems a bit overkill though.

If you want a challenge, maybe one of the 99p MMC readers connected to the Userport would work. Using MMFS or SmartSPI as a guide you could probably write the relevant calls

[BeebMaster]

I just had another look at the SD card, thinking I may try to read it again, and as I picked it up, I saw it has a crack all the way down it. I wonder how hot it must have got to start to shatter.

Another interesting thing I've found is that these Kingston cards have a lower capacity than others. A full image of a 32GB card amounts to 31,104,958,464 bytes, whereas a Samsung 32GB card will image 32,010,928,128 bytes, that's 864MB smaller for the Kingston card!

[BigEd]

Are cards always the same size? I imagine with bad blocks and some reserve for wear levelling, the apparent capacity could vary a bit depending on firmware and luck.

[KenLowe]

I just had another look at the SD card, thinking I may try to read it again, and as I picked it up, I saw it has a crack all the way down it. I wonder how hot it must have got to start to shatter.

Ah. I wonder if it got damaged when trying to plug the 1MHz RPi into the level shifter when the Tube level shifter and RPi is already in position. There's not quite enough clearance to push the 1MHz RPi (with card installed) past the Tube RPi without causing damage. It's safest to plug in the 1MHz RPi (with SD card), and then plug in the Tube RPi. Someone else damaged a SD card in this way. I may look at modifying the design of the 1MHz level shifter to give the SD card a little bit more clearance. It doesn't need much; probably only 1-2mm.

[BeebMaster]

No, not at all. It's all resting on the case of my Master, I have an extension cable from the 1MHz bus, underneath to the back that lands about 4 inches away from the speaker grille. The Tube one goes the other way, the extension cable comes fowards and goes over the numeric keypad to rest on top of a ROM cartridge. So the two aren't in contact at all.

[BeebMaster]

I may look at modifying the design of the 1MHz level shifter to give the SD card a little bit more clearance. It doesn't need much; probably only 1-2mm.

What about a combined board, both adapters side-by-side on the same PCB (but not electrically connected, except for power if necessary)?

[KenLowe]

I may look at modifying the design of the 1MHz level shifter to give the SD card a little bit more clearance. It doesn't need much; probably only 1-2mm.

What about a combined board, both adapters side-by-side on the same PCB (but not electrically connected, except for power if necessary)?

Hmmm. Now, there's an interesting concept. Not sure that too many people would be interested in it, but I quite like the idea!

[BeebMaster]

And here's a challenge for programmers - what about if it could take one Pi and run both the Tube and 1MHz bus?!

[KenLowe]

And here's a challenge for programmers - what about if it could take one Pi and run both the Tube and 1MHz bus?!

My initial thoughts were that it wouldn't be possible from a RPi GPIO pin availability point of view, but with a bit of cunning logic on the level shifter it might actually just be possible.

Firstly, I'm guessing it would be possible to derive the 1MHz clock in the RPi from the 2MHz clock?
And secondly, I'm guessing it would be possible to mux the nTube , nPGFC & nPGFD into a 2 bit signal, and then demux them again in the RPi.

If that was possible, then over to the software guys...

[BigEd]

Interesting thought...

It's the nTube side which is most time-critical, as it operates within a 2MHz cycle. After the first test for nTube, which would probably have to be changed to testing for a merged signal, there is some setup and then a second, deglitching, test for nTube. If this second test fails, the code presently goes back to the top. What it would need to do is to branch to a code flow testing for Fred or Jim accesses - the good thing about this is that we're now trying to operate within a 1MHz cycle and we know we're not burning through a Tube access time, so we have a bit of slack.

I'm not sure where we are relative to the rising edge of the clock, but that's checked shortly after.

First test here (label Poll_loop.)
Second test here (second read at delay_done, but tested some 8 instructions later.)

[dp11]

Splash the cash on another PiZero.

[Coeus]

Splash the cash on another PiZero.

I wonder how many ARM processors you can surround your BBC micro with. One in PiTubeDirect, one on the 1Mhz bus, one for an HDMI converter and on on an SD card or USB flash key. Any more?

[richardtoohey]

Not had any personal experience with flaming SD cards, but does look like it happens (including the cracking).

e.g. https://raspberrypi.stackexchange.com/q ... i3-model-b

[KenLowe]

Splash the cash on another PiZero.

Well, indeed, that certainly is the simplest solution.

And secondly, I'm guessing it would be possible to mux the nTube , nPGFC & nPGFD into a 2 bit signal, and then demux them again in the RPi.

And this is how I envisaged the mux logic working:

Code: Select all

nTube | nPGFC | nPGFD ||  RPi  GPIO  || Data  ||
  y2  |   y1  |   y0  ||  a1  |  a0  ||  nOE  || RPi Action
------+-------+-------++------+------++------------------------------------
   0  |    0  |    0  ||   1  |   1  ||    1  || Ignore - Invalid selection
   0  |    0  |    1  ||   1  |   1  ||    1  || Ignore - Invalid selection
   0  |    1  |    0  ||   1  |   1  ||    1  || Ignore - Invalid selection
   0  |    1  |    1  ||   0  |   0  ||    0  || Tube active
   1  |    0  |    0  ||   1  |   1  ||    1  || Ignore - Invalid selection
   1  |    0  |    1  ||   0  |   1  ||    0  || FRED active
   1  |    1  |    0  ||   1  |   0  ||    0  || JIM active
   1  |    1  |    1  ||   1  |   1  ||    1  || Ignore - Nothing active

I couldn't see any simple (low IC count) way to achieve this in discrete logic, but it would be easily achievable in a small PLD. I could also use the PLD to trigger the data buffer nOE signal. Currently I'm doing this with a discrete logic IC on the 1MHz level shifter.

[1024MAK]

Encoding the nTUBE, nPGFC and nPGFD to two lines can be done by a 74LS148, 74HCT148 or maybe a 74HCT147.
I’ve not looked at propagation times though.

The DATA nOE can be derived from a single three input AND logic gate (e.g. 74LS11, 74HCT11 or similar), as the Beeb’s address decoding will not allow any of the invalid states.

Mark

[KenLowe]

Encoding the nTUBE, nPGFC and nPGFD to two lines can be done by a 74LS148, 74HCT148 or maybe a 74HCT147.
I’ve not looked at propagation times though.

The DATA nOE can be derived from a single three input AND logic gate (e.g. 74LS11, 74HCT11 or similar), as the Beeb’s address decoding will not allow any of the invalid states.

Mark

I did look at the 148. I was just a bit worried that it wouldn't encode invalid states correctly. As you say, the beeb should never be able to set invalid states, so it would probably work just fine. For the Data nOE, I'm already using a single 3 input AND gate on the 1MHz board for JIM & FRED, with the third input held high, so yes I could use the third input for the Tube.

...but all very theoretical if the software doesn't exist!