Unable to write to Micro-SD card in AltariDuino

[Mark Moulding]

Following Frank P.'s good suggestion, I'm creating a new thread for this issue (previously it was part of Problems saving RAM page to file).  I've assembled a new AltairDuino, which went together smoothly and appears to work perfectly, except for one thing: the Micro-SD card acts like it's write protected.  I can read the card fine - I like CP/M, so I've attached two of the included hard disk images to platters of the virtual hard drive controller, and am booting and running CP/M, running programs, etc.  However, I'm unable to save anything back to the "hard drive".  I also tried just using the built in X-Modem transfer facility in the simulator's file manager, and it can't write to the SD card either.  Similarly, any change I make to the configuration (default start-up program, or serial port mapping) don't stick, because the STORAGE.DAT file can't be modified to save the settings.

Things I've tried:

• Reloading the firmware (I retrieved the latest version from GitHub, and once I got my head out of my butt the update worked smoothly)
• Re-flowing the solder connections to the Micro-SD adapter (shouldn't have made a difference, since reading worked OK - and it didn't)
• Using a different Micro-SD card (I used a 2-gig card - smallest I could find - formatted with the SD-Associates formatter and loaded with the files copied from the original kit Micro-SD)

So I'm stuck.  I can't think of anything else that would cause the card not to write.  There's no write-protect slider on a Micro-SD card, although there is a switch in the socket; I think that's to determine the presence of a card in the slot, but I could be wrong - it's always closed whenever a card is inserted.

What do I do next?

~~
Mark

[Colin Little]

This all seems very similar to the problem/symptoms I had back in January (see my post Jan31) Nothing seemed to make any sense until I re-loaded the firmtware again.. It may be worth trying , if you can, an earlier revision of the software 

[Mark Moulding]

Thanks for your response, Colin.  I read your thread from January, and it's not quite the same issue; it sounds like you could write to the Micro-SD from within the "monitor", but not within CP/M.  I'm unable to write at all, from anywhere.  Your situation would point to an issue with the virtual disk emulator, rather than the low-level write routines in the "monitor".

Nevertheless, I reloaded my Arduino environment, including the DueFlashStorage library and the board definition, and retrieved the 27-Dec-2017 commit to GitHub (since that seemed like the last full commit before your experience).  I recompiled and loaded and ... same results.  Still no writes to the Micro-SD, although reading works fine.

Aargh!

~~

[Chris Davis]

It works for me, and I verified I'm using the same SD card and SD card module that I'm sending with the current kits.  I'm sending you a new card and module.  Also, check your solder connections for the Arduino headers (including the SPI headers) with a magnifying glass if necessary.  90% of the problems I run into are related to those solder connections.

FWIW, I just remembered when I was demoing one of my Altairduinos at VCF, it would not write.  I'm going to find that kit and see if that's still the case.

[Mark Moulding]

Hi, Chris,

 

Thanks for checking into it.  At this point, I can’t see what else the problem would be other than the Micro-SD module.  I’m now certain that the soldering of the SPI connections is OK – I was pretty sure before, but I prophylactically re-flowed all of those connections again.  In any case, all the reads work fine, so that pretty much proves out that the SPI communications is working correctly.

I'm glad (sort of) that there's some precedent for this problem, and that you've seen it before.

 

Thanks for sending a replacement -  I’ll try that out as soon as it arrives.

[Frank P.]

Well that'll be pretty amazing if it turns out to be the module, because AFAIK it's passive - i.e. the 3 signal lines, chip-select, power, and ground just go to the corresponding pins on the card (Chris, correct me if I'm wrong on that). The chip-select is permanently enabled. There would certainly seem to be no pin that could be not-working that would cause writes to fail and reads to succeed.

[Richard Deane]

Could the power to card be a problem, writes are likely to be more stressful than reads. Voltage ok?

[Mark Moulding]

Thinking about it, I decided this was a heck of a good question, so I set up my scope and measured. The first picture is of the 3.3 volt power on the SD adapter itself, referenced to ground on the Arduino (a wire soldered to the power connector ground).  It shows about half a volt of noise all the time, rising to over a volt (shown in the capture) when the card is accessed.  There was no difference between reading and writing, though.  The second picture is even more bothersome: it shows the voltage at the card's ground terminal relative to the Arduino - again, about a volt.

So I applied my usual fixes for this sort of thing; I put a 1uF ceramic cap across the power and ground terminal of the SD adapter, and ran a heavy (20-gauge) wire directly back to the Arduino ground.  (I know this is a recipe for ground loops, but there's no low-level analog in this project, and I figured it couldn't be much worse than it was.)  After these fixes, the ground bounce was down to less than 100 mV, as was the supply voltage noise.

Oh, and the supply voltage was just where it was supposed to be, at 3.30 volts.

However, none of this changed the way things worked -I still can't write to the stupid Micro-SD card...

~~

[David Hansel]

Mark,

I think it would be good to determine whether this is a hardware or software problem.

I generally agree with Frank that it's hard to imagine a hardware problem that could be

causing this behavior since the only hardware is straight-through wires and all of them
are used the same for reading and writing. But who knows...

To figure out whether it's a software problem or not we need to upload a known-good
firmware, but that's tricky since the regular way to upload a firmware via Arduino is
to re-compile from scratch which could introduce problems with library versions etc...

I have attached a ZIP archive that contains the means to upload a known-good binary
firmware (which I've tested to confirm that writing to SD card works).

The archive contains the following files:

• altair8800.bin: binary of Altair8800 firmware for the Due.
  This was compiled from the latest sources in GIT with the A6A7 serial port enabled (like in Chris' instructions) and Z80 support enabled.
• blink.bin: binary of the small "blink" example for Due
  Can be used for testing the upload . After uploading the "protect" LED should blink slowly (obviously uploading this this wipes out the Altair firmware)
• bossac.exe: Executable to upload a binary file to the Due.
  This is part of the Arduino environment but it's tricky to find so I included it here.
• upload.bat:
  Batch file that prepares the Due for upload and calls bossac.exe with the correct parameters.

To use this, do the following:

1. Rename the file from .bin to .zip
   
2. Extract the contents into a directory
3. Start a Windows command prompt and "cd" to the directory created above
4. Connect a USB cable from your computer to the Due's programming port
5. Find the COM port number for the Due. The easiest way to do this is to start the Arduino IDE and look which port it is using.
6. Enter the following on the command line:
   upload altair8800.bin COMn [where n is the port number determined above]

This should upload and verify the firmware.

Now try and write something to the SD card in the Altairduino (in CP/M or whereever).
If it works, you know that there was some issue with the firmware you had compiled and uploaded before.
If it still does not work then it's a hardware issue.

[Frank P.]

David, change the extension on the file from .zip to .pip, post it to here, and tell those who download it to change its extension back to .zip.

On Thursday, August 16, 2018 at 6:16:38 PM UTC-4, David Hansel wrote:

Unfortunately Google won't let me post this message with the ZIP file attached.

[David Hansel]

Thanks Frank, that worked! I thought I had tried that before but either I made some mistake

or adding a file via an edit is less restrictive :)

On Thursday, August 16, 2018 at 7:03:39 PM UTC-4, Frank P. wrote:

David, change the extension on the file to .txt or .pdf, post it to here, and tell those who download it to change its extension back to .zip.

[Mark Moulding]

Hey, David, thanks!  The stand-alone updater is great, and will actually be very helpful to me for another application (I manufacture some special-purpose industrial devices based on Arduinos  - I just use the raw chips and the Arduino IDE.  This will give me the ability to have my customers do field updates - excellent!)

I'm not at my bench right now, but I'll give this a try later tonight.  I've always thought that the problem is software, but this will identify it one way or the other with certainty.

~~

[Chris Davis]

Have you tried writing from within the configuration menu (raise STOP+AUX1)?

Go to the file manager (F) and try the copy command (c) and see if that writes to the card.  For example, copy README.TXT to READCOPY.TXT.

[Chris Davis]

I actually found a problem saving on one of my demo units.  I have no problem at all writing to the SD card from the file manager in the configuration menu, however, I cannot save anything to the SD card from within MBASIC in CP/M.  If I try to save a program (eg SAVE "PIZZA") the lights flash but nothing is saved.  If I try it again, I get this error: "Bdos Err On A: R/O".  On one of my other demo units, I can save just fine from within MBASIC.

Both units are using the exact same style SD card.

[Udo Munk]

Have you guys ever checked that the files on the SD card have write permission set?
A write protected disk image would behave as described, because the ugly MITS
FDC has no status for write protected disks. That only can be verified with a read after
write, and this feature usually is turned off in CP/M for this thing.

[Chris Davis]

Good call.  I found this in some very old documentation from 1980:

If the computer responds with "BDOS ERR ON A: R/O," then the disk to which you are trying to copy is write-protected

I will check that when I get home.

[Mark Moulding]

Awesome! It now works!  The image you posted uploaded without a hitch, and now a "save 1 x.com" typed to the CP/M prompt creates a nice X.COM file in the directory.  That uploader you posted works a treat, too!  (I still think of that as "downloading", though...)

Obviously it was a software problem of some sort; I sure wish that I knew where it was, since I used a fresh installation of the Arduino IDE, and also downloaded the latest (the same one you used, I believe) from GitHub.  Plus, it didn't work before I started replacing the firmware.  I really don't quite know where to start finding the problem, either...

However, at least I can now run the CP/M system I was hoping to.  Next stop: replace the Bluetooth module with a second serial port, and fire up the H-19 terminal as the system console.

Thanks again, everyone!

~~

[Joe Cracchiolo]

I had the same issue as Mark and I can confirm that the reflash of the Duo fixes it.  Thanks for the posts everyone.

Joe

On Thursday, August 16, 2018 at 3:16:38 PM UTC-7, David Hansel wrote:

[minwa...@gmail.com]

I have recently bought & build an Altairduino and had the same problem. I can also confirm David Hansel's suggestion above fixed the issue - many thanks David!

It also seemed to fix another problem (I thought unrelated) whereby the prompt in Hitchhikers Guide and some other adventures would not appear, and some other issues playing the games in the terminal.

[Mark Moulding]

So it appears that there may have been a batch of units with a firmware issue in the Arduino.  It's great that David's firmware image fixes the problem so well.  (And I still love that upload utility!)

I just wish I could recompile an image correctly; I'm using the latest Arduino environment (1.8.5), and have updated my libraries (specifically, the SD library - I did have a problem with the earlier one I was using).  However, when re-compiled and uploaded to the Due, the problem re-appears.

[Frank P.]

There appear to be only 2 library layers between the Altair8800 firmware and the Arduino and SD hardware. These would be the "SD" library (called by the firmware) and the "SPI" library (called by the SD library).

There is only one version of the "SPI" library, 1.0.0. Therefore there could be no variability there.

There are many versions of the "SD" library. I am using 1.1.1 on the advice of folks in this group. But there are also versions 1.2.0, 1.2.1, and 1.2.2, the last of these being noted as a potential problem here in the group. And there are many versions prior to 1.1.1. The questions is, which are you trying to use, Mark? If 1.1.1, then this is truly a mystery. I would give the other one a try (i.e.: try 1.1.1 if using 1.2.2, or try 1.2.2 if using 1.1.1) to see if this has any effect. I suppose a newer version of the firmware (than what I'm using) could for some reason require 1.2.2.

There really has to be an answer to this!

[Mark Moulding]

I am using version 1.2.2.  Since that's been flagged as a potential issue,  I'll try loading version 1.1.1 and see if that makes any difference.

~~

[Frank P.]

Check out these posts to see the 1.2.2 issues discussed:

https://groups.google.com/forum/#!searchin/altair-duino/1.2.2/altair-duino/_KDfaJBuLAg/u9b9Zfc5CQAJ

https://groups.google.com/forum/#!searchin/altair-duino/1.2.2/altair-duino/svx4WjxC6Ho/rw6Nf-yFBAAJ