CID change on SD card update (evoplus_cid)

IMG_20160731_172654

My recent post on how to change the CID on a Samsung Evo Plus SD card has generated some interest, but also a number of people who are having problems with it. I thought it was worth posting an update with some extra information. First off, I suspect some people who are struggling have fake cards – there are a lot out there and some of them look pretty convincing. Others have suggested different hardware / firmware revisions might be an issue – quite possible but I have no way of knowing (all my Evo Plus cards work, so I can’t can’t compare against ones that don’t). I can see no reason why different phones etc. would give different results – as long as it’s a proper SD controller (not a USB mass storage adapter) then sending the command should work just fine.

Fake cards
These are very common and if you google for fake Samsung cards you’ll find lots of info on how to spot them. A few tip I’ve picked up along the way:

  • Packaging quality – the image should be well printed, in high resolution and good bit depth on the colours (some fakes looks like they’ve been converted down to 256 colours). The gloss overlay over the printed areas should align with the printing below them, if it’s offset that’s a bad sign.
  • Packaging info – the product information should be correct and match the card. I had one fake that incorrectly stated a 32gb card was SDXC on the pack instead of SDHC, the card itself had SDHC printed on it. The correct size should also be printed on the packet. Look up the UPC from the barcode on the back and make sure that matches the product and size of your card.
  • Hologram, with scratch-to-reveal verification code. The real ones have them (recent ones at least), fakes might but probably don’t. All of mine have, but oddly enough when I tried to check one on the Samsung China website I didn’t get anywhere with the verification code, the site was in Chinese though so I might have been doing something wrong.
  • The card – lots of subtle details to check. Smooth back, not lumpy showing circuit parts beneath the surface. Black on the back, white on the edges. Slight bevel on the contact side, to help insertion. Correct info printed on the card. Correct font, especially for the capacity digits, some fakes don’t use the correct slim font. Text on the back is printed so it is read with the card contacts end pointing upward. Mine are made in the Philippines but this is probably not the only place so don’t get hung up on this.
  • Card CID – check it and compare to working ones. See below…

Card CID
An example of the CID on one of my cards: 1b 534d 3030303030 10 98625deb 0102 a1. Your card CID should be very similar. The manufacturer ID should be 1b, followed by an application/OEM ID of 534d. The product name is 3030303030 (5 x ASCII ‘0’). The product revision is 10 (1.0). The next 8 hex characters (98625deb) are the SD card serial number, yours will be different! The manufacturing date is next (0102, or 0 10 2), where the first digit is ignored, the next pair is the year in hex since 2000 and the last digit is the month in hex. So this is February (2) 2016 (2000 + 0x10). I also have March 2016 (0103) cards that work fine. Last is the checksum (a1) which will be different on your card. I doubt many of the fakes have properly set Samsung CIDs so hopefully this is an easy way to tell.

My cards / System
Samsung Evo Plus 32gb. UPC: 8806086928410. Model: MB-MC32D. Model code: MB-MC32D/CN. Purchased from this listing on AliExpress. I am not affiliated with the seller and get no referral commission from this link. I also cannot guarantee that you’ll get working or even genuine cards, but I have purchased on two occasions from this seller and the cards have been genuine and worked with evoplus_cid.

I have used evoplus_cid on a Samsung Galaxy Tab 2 (10 inch, wifi model, p5110). The tablet is running CyanogenMod 13 unofficial from here.

evoplus_cid
I’ve made a couple of updates to evoplus_cid. If you supply a full 32 digit CID (and don’t apply a serial number modifier) it will be written as is without recalculation of the checksum. This was requested by a user for cards that apparently always had a checksum of 00. Although, I’ve got a laptop that always displays 00 for the checksum when showing the CID, so I wonder now if his cards really did need that! I’ve fixed a bug when compiling on 64bit Linux that could prevent the CID being written. I’ve also fixed a bug causing the displayed CID to include some extra ‘FF’s.

Pictures

Turret clock restoration progress report

DSCF3706

I thought a progress report was in order for the turret clock we (my father and I) are restoring, after I realised we started this project way back in November 2014! As a refresher the clock is a 1922 cast iron flat bed turret clock made by John Smith & Sons of Derby. It was purchased in a poor state of repair, having been butchered in the 1950s to make it electric drive and later having much of the electrics stripped back off. The original parts removed during the motorisation would have been recycled at the time so were no longer available to be replaced, later removal of the motors (etc.) just left the clock in a non-working state.

Since November 2014 a lot has been achieved. We now have fully working striking and chiming trains and the going train finally feels like it’s well on its way to completion. I’ve tried to list out everything that has been made or sorted so far. Pictures of the current state of the clock are below, along with some pictures showing details of recent additions to the going train. The red parts are all new, as are quite a lot of brass parts and several steel arbours which haven’t been painted. Eventually the clock will be properly painted but in the mean time the red primer makes a nice contrast between the new and original parts. There are a few temporary supports and bolts in the pictures, but this is still very much work-in-progress.

Striking & chiming trains

Going train

Other

  • Removed 1974 plaque (covered maintaining power hole) and patched bolt holes
  • New maintaining power – arbour, front bush, pushing mechanism, arm and weight
  • New winding handle

Our first bell

bell-ebay-2

I’m already resigned to the fact that I’ll never own the set of 8 full size church bells intended for the chiming train. However, I do now have one so the clock will at least be able to strike the hour. This is a proper bell too, exactly like you would find in your local church. Admittedly it’s at the smaller end of the scale but it really looks the part. It was cast by John Taylor & Company Loughborough who, just like Smith of Derby who made the clock, are still going today. I bought the bell a couple of weeks ago from a retired GP near Tamworth via e-Bay. According to the listing it was “probably made around the turn of the 19th/20th century for a school in Norfolk possibly Stoke by Nayland”. It came with a substantial bracket and was intended to be wall mounted and rung by pulling a chain. The bell itself is 12.5 inches in diameter, 13.5 inches high and weighs 56 lbs.

The previous owner of the bell did say that he’d had the bell checked out and that the length of the ringing tone was slightly shorted than it should be and so there could be a crack. It rings well to my ear and there is certainly no visible defect so I’m happy with it. Don’t forget that Big Ben has been cracked pretty ever much since it was installed, mind you Big Ben doesn’t sound particularly good so that’s not saying much. The funny thing here is that before this bell went on eBay the previous owner offered it to UK Architectural Antiques in Staffordshire, but they weren’t interested because of this potential defect. This is the same company from whom I purchased the clock which, it should be fairly clear from this blog, was a long way from being in mint condition!

Positioning a new arbour

IMG_20160621_194002

Now we have our new wheel we need another new lantern pinion to engage with it and that pinion needs to be mounted on another new arbour. The position of the arbour needs to be chosen carefully to ensure a good mesh between wheel and pinion. Our horizontal position is fixed – it needs to sit central to the rest of the escapement position. However, we can choose the vertical position, up to a point, to ensure the correct mesh. The vertical position of the remaining escapement parts (still to be made) will then follow.

To aid the positioning of the arbour Dad made a little tool which can have the wheel and pinion mounted on it allowing the mesh to be perfected, before scribing the arbour position (where it crosses the horizontal midline). I’ve attached pictures showing the tool for this clock and a smaller version he used previously when making a couple of long case clock movements. The new tool (that’s the bigger one, in case you hadn’t guessed) isn’t quite finished as you can see compared to the original. From the pictures you can see how the mesh is adjusted with the wheel and pinion mounted on the tool. Then the tool’s wheel arbour can be placed in the bearing on the clock and the tool rotated to see where the pinion’s arbour crosses the horizontal midline and the position scribed.

Cutting a new wheel

Test cut wheels in plastic and brass.

So far we have needed to create several new lantern pinions but no wheels, until now. The next missing part of the going train is a wheel and we have already worked out how many teeth it needs (72 based on a 1.25 second swing of the pendulum). Based on the 72 teeth, and the dimensions of the arch made based on measurements from St. Alkmund’s clock, we ended up with a diameter of 4.522 inches. The pitch circle diameter of the 9 pin pinion it engages with is 0.478 inches.

Cutting the wheel should be easy in theory, with a milling machine and a dividing head, although finding the right cutter isn’t. These wheels should have epicycloidal teeth of a decent depth, to engage with a lantern pinion, but you just can’t seem to get suitable cutters any more. One option would have been to make a fly cutter, but we managed to avoid the need to do that. A test wheel cut with involute teeth and deepened slots seemed to work pretty well so we decided to go with that. The first test was cut in a bit of plastic fascia board, then a section was to be test cut in brass on a blank made from an old engraved sign. Dad got a bit carried away and cut the entire thing and after spending so many hours on it we decided to keep it, despite the remnants of engraved lettering on one side, at least for the time being. After the cut-outs to form the spokes there won’t be a lot of the lettering left and a little metal filler, maybe even a touch of brass coloured paint, and the last traces will disappear. If not we can always replace it later, but in the mean time we can move on to the next part.

The dividing head was from my Dad’s Myford ML7, but was set up on an unbranded ‘Micro Mill’ because it gave a better view at the point of cutting.

Changing the CID on an SD card – Working!

(tl;dr – skip to bottom for instructions, see also update post) The CID register on SD cards is supposed to be read-only, which means it can be used to lock devices to specific SD cards, preventing the user swapping them out, which is very annoying. This can result in you being stuck with a smaller card than you’d like in a device or not being able to use a backup in case of damage.

I’ve spent a while trying to work out how to change the ID on some cards. There is surprisingly little info out there about this, when it’s easy for other devices. For example, if you want to change the supposedly read-only ID on various kinds of RFID tag you can simply buy a special version from China that allows it (often referred to as gold or magic cards). There are rumours of cheap Chinese SD cards that don’t follow the official spec and allow you to change to them – I now have  large pile of cheap Chinese SD cards on my desk, but unfortunately none of them did allow it. The spec includes a command (CMD26) for writing the CID, but it’s only supposed to work once in the factory when the card is first assigned an ID. All the cards I got seemed to honour that restriction. However, there is probably some way to unlock them…

If you’ve found this page by looking for help on this topic you’ve probably already seen Bunnie Huang’s SD card hacking presentation, unfortunately I wasn’t able to track down any APPO AX211 based cards, which I thought would be my best bet.

In that presentation was mention of vendor commands for a Samsung eMMC used as the built-in storage on an Android phone. I’m not well enough versed on the technology to know quite what the difference between eMMC and SD cards are, aside from the way SD cards are packaged of course – although that might be all there is to it. Reading around they seem work in the same way and appear the same within Linux. Then I stumbled upon SamDunk, where Sean Beaupre had managed to unlock a Samsung phone (to developer mode) by reverse engineering some of the eMMC firmware on his device and finding commands that allowed the CID to be unlocked and rewritten.

So I started buying Samsung SD cards, hoping for one with the same moviNAND core as the eMMC in their phones. I now also have a stack of Samsung SD cards on my desk, but with the last different one I found I struck gold! (Collecting Samsung cards is more expensive than cheap Chinese ones and it takes some effort to avoid getting fakes.) The Samsung EVO Plus 32GB MicroSDHC card took the commands from SamDunk and let me change the CID.

I have taken the SamDunk code and reworked it a little to make it easier to use for SD cards, but all the credit really needs to go to the original author. To use you simply need a rooted Android device with an SD card slot. Copy the evoplus_cid binary to the device and put it somewhere with a proper Linux file system (not FAT), then apply execute permission to it. Run the tool and point it to the SD card device e.g. /dev/block/mmcblk1 (you almost certainly do not want to use mmcblk0, that is likely to be the built-in storage on your device). List the /dev/block folder and make sure the device you going to use appears and disappears as you insert and remove the SD card to be sure. Supply the new CID you want to set on the command line. If you only need to change the card serial number (part of the CID) you can supply the old CID and the new serial number and the new CID will be calculated for you. I suggest you make a note of the old CID first, in case you want to set it back later. This can be found in the file like /sys/class/mmc_host/mmc1/mmc1:0001/cid, but the path may vary, and again make sure you are looking at the right card by checking it disappears when you remove the card.

You can find the code here: https://github.com/raburton/evoplus_cid (compiled binary is in the lib folder). Use entirely at your own risk. Use only against genuine Samsung Evo Plus cards, anything else is unlikely to work and could be damaged. Even the right card could potentially be damaged!

To set a new completely new CID:

# Usage: ./evoplus_cid <device> <new cid>
./evoplus_cid /dev/block/mmcblk1 744a454e2f412020106c6d77470104c3

Or to just change the serial number part of the current CID:

# Usage: ./evoplus_cid <device> <currentcid> <new serial>
./evoplus_cid /dev/block/mmcblk1 1b534d30303030301098625deb0102a1 12345678

Freshly cast pendulum support

Newly cast pendulum support.

The pendulum support has been cast and we’ve just got it back from the foundry. It’s not quite finished yet though. It needs a bit of light sanding to remove some of the casting marks on the edges. Then it needs the bottom of the two feet flattening so it sits nicely on the clock’s frame, plus bolt holes drilling. Recessed areas needs to be milled to mount brass plates on the front and back. Finally, a v-shaped groove needs to be cut across the top for a small bar to sit in,  from which the pendulum actually hangs. This is another significant chunk (literally) of the clock done, or almost done, and allows further progress to be made on building the new escapement.

Pendulum support casting

Pendulum casting pattern, front view

This is the first update for a while on the clock, but we are still working in it. It was a bit cold for spending long in the workshop over winter. Then, as things picked up in spring, there were plenty of other priorities. As well as creating the pattern for the pendulum support casting we now have all the key measurements and positions worked out for the escapement. We have also started work on another missing wheel (but more on that in another post to come).

When the clock was converted to electric drive it was became little more than a gear train from the motor to the drive shaft. It no longer used a pendulum or escapement and unfortunately these were not kept with the clock. The pendulum would have been mounted on a large cast iron wishbone-shaped casting at the back of the clock. The arms of the escapement were also attached to this structure.

The pattern for the casting was made out of a couple of chunks of pine joined together. The basic shape was cut out with a band-saw. A small amount of hand carving was required for fine details and wax fillets were applied to the recessed front edge. Dimensions for the arch were taken from the clock of St. Alkmund’s Church, Duffield. The measurements were taken in situ, from the top of a ladder, while the clock was going. As a result they may not be quite 100% accurate, but very close to the original.

My father approached a couple of local foundries about casting the pattern. I was surprised there were any local foundries left, let alone a choice, but then Derbyshire was the birthplace of the industrial revolution! Neither of us really knew how much it was likely to cost but we were disappointed with the first quote of over £160. In the end we managed to get it for £55, with a 3 week turnaround. We’re still waiting and I’ll post pictures once we get the finished article. It’s going to need a little machining to complete. The base needs to be made flat and a v-shaped groove cut across the top for the pendulum to sit in. It also needs to accommodate two brass plates, one on the front and one on the back, to mount the arms of the escapement.

Flash write bug fix

Looks like I finally have a fix for the flash write issue, thanks to some help from Espressif. Embarrassingly it turns out to be my fault, but I’m not too proud to admit that. So what was the problem? Since SDK v1.5.1 people have been reporting intermittent failed OTA updates and I’ve been able to reproduce it easily myself. This only seemed to occur when using wifi for long sustained writes.

So what was happening? Occasionally the network receive would get a much larger packet than normal. In my latest testing they are usually around 1436 bytes, but occasionally one would arrive that was 5744 (this is the only large value I have seen myself, but presumably other values could occur). The flash is erased in 4k sectors and the rBoot code erases them as required, checking if the current data block will fit in the current sector and if not erasing the next one too. Where I went wrong was to assume that a receive would always be less than the 4k sector size, having never seen one before SDK v1.5.1 that was anywhere near that large. When one of these very large packets arrives it could span 3 sectors. The second sector would get erased correctly but the third sector would not. The flash write command would not return an error when it tried to write to the non-erased sector, so no fault was noticed at this time. Then on the next write that third sector, now being the first sector for that next write, gets erased and the new data written part way through it (where it should be).

Moral of the story. Don’t make assumptions and don’t ignore the edges cases – I’m usually pretty good at this second point, but occasionally I seem to need reminding. In this case I had thought about it and added code that detected a chunk over 4k that would need more erasing. As I didn’t think this could ever happen I merely put a comment in the if statement to say what would need to be done in that scenario, if I’d thrown an error at that point instead this problem would have been easily diagnosed. However, I did also assume that the flash write would fail if it tried to write to flash that was not erased, so I expected to see an error of some kind.

Why did it suddenly happen at v1.5.1? I don’t know that but presumably Espressif made some change in the SDK that makes this more likely to occur. While playing with some code for Pete Scargill I did manage to reproduce the problem with v1.4.0 so it wasn’t impossible for it to happen there, but I never had any reports of it there previously. I also found that the timers in Pete’s code made it more likely to happen in my testing, so I suspect the extra processing these caused was impacting the performance of the network stack and causing more packets to be bunched together and delivered as larger chunks to the application. Further testing showed RF interference could also cause the same result.

The fix is available in the rBoot GitHub repo, and has also been updated in Sming.

Flash write bug in Espressif SDK v1.5.1+

Users of rBoot have reported OTA problems when using Espressif SDK v1.5.1 which I have been able to reproduce on this version and v1.5.2. The problem appears to be in the sdk flash write functions. While most writes work fine some will occasional fails to fully write (leaving small areas of blank data (0xff)). To make matters worse no error is reported from the write function and attempts to read the flash back for verification immediately afterwards return the correct data (presumably they are serviced by the rom cache). This is very similar to the problem seen when trying to perform an OTA with insufficient power. I once had a similar report from a user using just a 100mA power supply and the problem was fixed by using a proper power supply. This makes me wonder if the new SDK causes the device to draw more power, although supplying extra power does not fix the problem in this case.

I have created a test case that doesn’t use rBoot but simply downloads a file and writes it to flash (which is of course very similar to what rBoot does) to demonstrate the problem to Espressif. I have yet to hear back from them. If you encounter this problem please add your support to my bug report. I have no reason to believe this bug will be limited to rBoot users and I assume SDK bootloader users and anyone else writing to the flash from an application (possibly only in long sustained writes) will also have this problem.

This is a good opportunity to encourage rBoot users to enable the irom checksum option, to help detect badly flashed roms at boot time. See the readme for more information.