PC Usage = Mode4 MicroSD card = !Only!

Tried another card in a 32G variant. Another Sandisk.

Appears slower MODE 4 cards take to PC OS formatting utilities, as
recognized as a drive, through a USB adaptor layer. Faster cards, at
least those Sandisk offerings I did try, do not.

A PC format subsequently causes the card to fail.

Write operations to the MICRO SD causes OS to disconnect the USB
device, and subsequent attempts to format report back an OS,
un-specified error during the format.

Sandisk as well provides its own utility to format FAT32. Once the
partition has been erased and then recreated, however, their utility
is of no help. The drive will be again dismounted.

I have not tried the other principle maker among regarded Micro SD
quality, the Samsung's EVO series cards. Nor am I sure how and if
Mode 4, as a slower, less-technologically advanced product, stands in
view of obsolescence.

ExFat is big in the handheld scheme of things, including some 32G
cards, and exclusive to those above 32G.

Hence, Fat32 and the Micro SD format can be asking for trouble.

I paid, BTW, a couple bucks more, w/ state taxes, for a local
retailer, for the ease and comfort of having my money returned.

I then subjected the 32G card to PC Format Hell, which it passed with
neither minor, questionable, nor glaring major issues.

(Which is good for Sandisk. . .

I intended to format and disable every model on store sales rack,
otherwise, until either I'd exausted them all, or found one which
functions properly, not only with Sandisk's so-called FAT32, but the
proper PC definition and implementation of FAT32.)

On Sat, 17 Dec 2016 02:16:02 -0500, Flasherly
wrote:

.... but the proper PC definition and implementation of FAT32.)

-
I had to belabor that.

An MP3's app-specific, handheld's ROM, which I need to read by both
blocks (floating-gate NAND 4K-page addressing), so as to correspond
both sequentially and physically.

There however occurs SD NAND block-erasure issues, particular to the
app-device, so as not to be able account for subsequent page erasures.
Proper re-addressable alignment of data added (read on a page bases
from erased entries on a block basis) is not possible. The solution
-- possibly due to the app-device's lack of a MMU's (Memory Management
Unit) virtual extension to RAM overlays -- for correct alignment to
any changed file pointers is implementation of a FAT32 format
routine;- the reciprocal partition, beneath the file system, need not
be removed (and re-initiated). The buffer writes, ordered prior on a
PC for files being sent to the card's NAND, are newly laid in fresh
page alignment for correct app-device ROM bus addressing the NAND
controller.

Altogether, I couldn't imagine this is anywhere near an inconvenience
involved for most any other handheld to be successfully marketed. An
equivalence for SD storage considerations -- SD suffices to
approximate by some handhelds for embedding augmented programs -- to a
corrupted HDD requiring a reformat every time a program or other data
is added to storage.

An overhead involved, as it were, in apprising numerically from a
15-entry keypad an odd 10K of discrete MP3 entries. Without a web
service subscription or the extraneousness usually associated with
devices near in size to a deck of cards.

One of those things that pops up occasionally within a vague framework
of uniquely intuitive Chinese conceptions.