Cannot write files to SD in ESP32 port about runcpm HOT 24 CLOSED

DISK OR DIRECTORY FULL

So it is not a case of PEBCAK that I have this problem too: #74 (comment)

I saw it on boards with WROOM32 and with WROVER32(-A). Unchecked on WROVER32-B.

from runcpm.

the sdfat examples work fine. tried with external and internal CCP.... cant imagine what the problem is.

from runcpm.

The message is definitely coming from the card layer, as it is not from RunCPM.
I wonder if the write-protect mapping is not correct?
Or maybe we are not initializing the card correctly for this specific board model?

Can you show which is the code that actually works (the simplest one) on the examples?
Maybe we should use different initialization for your specific card.

from runcpm.

in the arduino examples.

Initialization :

SdFatSoftSpiEX<MISO,MOSI,SCK> SD;
#define SD_CS_PIN SS
if (!SD.begin(SD_CS_PIN,SD_SCK_MHZ(25))) {
    Serial.println("initialization failed!");
    return;
  }
  Serial.println("initialization done.");

Creating a file:

myFile = SD.open("F/0/test1.txt", O_CREAT | O_WRITE);

  // if the file opened okay, write to it:
  if (myFile) {
    Serial.print("Writing to test.txt...");
    myFile.println("testing 1, 2, 3.");
    // close the file:
    myFile.close();
    Serial.println("done.");
  } else {
    // if the file didn't open, print an error:
    Serial.println("error opening test.txt");
  }

Works fine ( i am writing the file to drive F so, i can see it in RunCpm)

in RunCPM:

#elif defined ESP32 // ESP32 boards
  SdFatSoftSpiEX<MISO,MOSI,SCK> SD;
    #define SDSPEED SD_SCK_MHZ(25)
  #define SDINIT SS // CS
  #define LED LED_BUILTIN // TTGO_T1=22 LOLIN32_Pro=5(inverted) DOIT_Esp32=2 ESP32-PICO-KIT=no led
  #define LEDinv 0
  #define BOARD "LOLIN D32"

_sys_makefile (ignore the added debug lines)

int _sys_makefile(uint8 *filename) {
	File f;
	int result = 0;

	//digitalWrite(LED, HIGH^LEDinv);
  Serial.println("Make File...");

	f = SD.open((char *)filename, O_WRITE | O_CREAT);
	if (f) {
		f.close();
		result = 1;
	}
  //result=1;
	//digitalWrite(LED, LOW^LEDinv);
  Serial.println((char *)filename);

	return(result);
}

Cant see any difference, but this routine fails.

from runcpm.

Not a write protect issue, a i can remove files with del command. :-)

from runcpm.

from runcpm.

Any chance it can be a bad library?

I had the same effects on ESP32-Wroom and ESP32-Wrover(-A) boards. So it is not a strictly local installation or library download problem.

from runcpm.

But, when you say "had", did you fix it?
I have not seen such issue here with the two different ESP32 boards I have.
So I am wondering that it has to be something specific to the building environment.

from runcpm.

I mean "had" like "a while ago".
And then finding no solution I gave up.
:-(

from runcpm.

Just for sanity check I have upgraded my SdFat library from 1.0.7 to 1.1.0.
Made the changes to ENABLE_EXTENDED_TRANSFER_CLASS and ENABLE_SOFTWARE_SPI_CLASS.
Recompiled, loaded onto the two ESP32 boards I have (TTGO_T1 and LOLIN32_Pro) and tested.
Everything works fine. So I am wondering what may be different between my environment and yours.
I am imagining insane things like:
. My boards have on-board sd-card adapters.
. I am using a 2D Micro-SD card.
. My card is formatted as Fat32.
. I formatted my card using the SD Card Formatter by Tuxera.
All things being equal, I am running out of ideas. Unless I can have one of your boards to physically test.

from runcpm.

Hey guys ... any luck here?
I find it strange that it is consistently working for me and consistently not for you.

Let me know.

from runcpm.

Closing this one as "Can't reproduce / Can't fix".
Feel free to reopen if more clues appear.

from runcpm.

I spent a morning on this one and I found a solution! I have 3 ESP32 modules running RunCP/M out of the box, multiple SD cards, all reformatted to Fat32 and then files/directory structure all cloned. It seems to be a write issue, and for me it comes up when Wordstar boots and it gives a "bdos error on [drive]" This sent me off on the wrong trail thinking it was CP/M but it is not. It appears it is the brand of SD card. Sandisk works. Kingston works. No Name "MicroSD" ones do not. The cards are all 1gb to 4gb. Hope this helps someone :) Cheers, James

from runcpm.

​@moxhamj: Wow. This may be a solution!

My errors were directory related.

I only have few SD cards more than I need and the ones I tried with different ESP32ers (Wroom and Wrover) were Intenso (4GB Class10), Sandisk (2GB Class unknown) and Nonames (2GB Class unknown). They did work with the previously used (slower) SD lib and I use them without problems in other contexts too. So I did not really question the cards.

A library being so picky, is it really intended to be that way or is the newer library overly aggressive?

Hmmm... looks like I need more SD cards...

But 1st I have to end my overly long Thursday. My eyes really need some hours without screens.

from runcpm.

I tried a quick experiment dropping the clock rate (I think in the ifdef it is the sd begin that does not have a clock rate, so not sure what the default is). Started at 50mhz, tried dropping to 4mhz but wouldn't work with any cards then. More experiments to do. I know with other emulations eg the FPGA ones, the biggest problem source of bugs was also different SD cards.

from runcpm.

Cool. Hopefully messing with the clock would solve the problem. I wonder if there's something I could do from inside RunCPM to help. Like drop a clock to x if writing at y fails.
Can't promise, as I am unable to replicate here, all my cards seem to work fine.

from runcpm.

I'll keep experimenting. Yeti mentioned in another thread about a directory error message - I recall seeing that too. There are lots of "CP/M" type error messages but I suspect they are actually related to the SD code. It is very handy that I have 5 SD cards that work and 2 that do not, so can swap them back and forth and test things. Strange that the non-working ones read fine but don't write. (They write fine when in a PC with a USB adaptor). I might try shortening the wires to the SD card (I'm using ribbon cable, who knows what sort of crosstalk there could be, plus at high frequencies, a 10cm bit of wire is a resistor, a capacitor, an inductor and an antenna). I might also go back to the ESP32 SD demo code as this reads and writes some files. Quick internet search, is the default frequency 20Mhz? I saw that somewhere. If so, I reckon that would be right on the threshold for breadboard style wires to an SD card. At least we are nailing this bug down a bit :)

from runcpm.

I might try shortening the wires to the SD card (I'm using ribbon cable, who knows what sort of crosstalk there could be, plus at high frequencies, a 10cm bit of wire is a resistor, a capacitor, an inductor and an antenna).

I had the same problems with boards having a SD card slot and with the ones where I had 10 cm long jumper wires between board and SD card. Both setups seemed equally often to fail.

from runcpm.

More experiments August 2nd regarding the SD card and ESP32. Simple test for writes - start MBASIC, write a one line program and then save it. Works with sandisk and kingston, not with no-name sd cards. Tried very short leads, no change. Ok, on the arduino IDE once ESP 32 is installed, File/Examples/ESP32 examples,/SD(esp32)/SD_Test., this appears to be the official SD code for the ESP32, and indeed it works fine for every SD card I can find. So... what would it take to port this code into the RunCPM? Lots of #ifdefs I suspect. There are some syntax changes, for instance, no need to declare which pins are which as these are fixed. And there are two SD.h files that are different, so need to tell the compiler which one is being used (more ifdefs). And then there are slight differences in the way functions are called, eg in runCPM to append a file

f = SD.open((char *)filename, O_WRITE | O_APPEND);

and in the ESP 32 example it is

File file = fs.open(path, FILE_APPEND);

Quick perusal through the code, I dunno, 20 to 50 lines need changing.

from runcpm.

Deep inside the code thinking about how to incorporate the working ESP32 SD code.
Meanwhile, tiny little hack I have wanted to do for years - file tranfers between CP/M machines using PIP. The ESP32 is cheap enough you can flash a couple of boards, and then link them with cheap RS3232 to TTL modules. (or directly, but I zapped some other boards a while back inadvertently linking 3V and 5V boards, so prefer the robustness of RS232). Added in Serial1 and linked it to the PUN and RDR CP/M calls.
On the sending machine PIP PUN:=LOREM.TXT,EOF: (sends a ^Z at the end)
On the receiving machine PIP TEST.TXT=RDR:
and it transferred the file! No need to patch xmodem, this is CP/M running out of the box. Of course, the characters are truncated to 7 bits and I added this in the same way as the CON, so can't send binary files. But can always use LOAD and UNLOAD to send hex files, which includes the checksum in each line. I also was able to transfer files to and from TERATERM and you can type ^Z on teraterm and it ends the transfer. Thoughts on whether the PUN/RDR is more useful sending to files or sending to serial ports?

from runcpm.

I am having the same issues of unable to write to cards.
As a quick test, I try this command: pip x=con:
After a few seconds I get a disk space error.

If I compile posix under Linux, the above command works.

I am running the latest arduino (1.8.9) and have tried the sdfat + adafruit_sdfat libraries.
I have tried with the stock config as well as I edited the 2 lines mentioned in the src.

If it is working for you, what version of arduino software are you using?
What sdfat version?

http://web1.foxhollow.ca/RunCPM/ttgo-no-space.png

from runcpm.

Two solutions: 1) is to try different SD cards, some brands work, some do not. 2) is to recode the simulation so it uses the official ESP32 SD driver code.
The second is the harder option as it involves rewriting quite a lot of the program. I have taken some very stripped down code just to write a few bytes to and from an SD card and can replicate the fault on some SD cards with the existing code and also that it works perfectly with all cards tested with the official ESP32 code. More work to do...

from runcpm.

I'm experiencing this problem (or something very similar) as well, compiled with the current Arduino on Windows 10 on a TTGO T1, using the 60kb DR CCP.

Attempts to write a file with e.g. mbasic result in a zero-byte file being created and CP/M crashing, regardless of initialization speed.

Also, I don't know if it's related, but when CP/M crashes, pressing the reboot button on the T1 results in CP/M starting, then failing with "unable to initialize SD card". If I unplug and reconnect the board it then boots correctly.

Edit: I seem to now have a correctly-working system, by virtue of changing some of the board settings in Arduino. Specifically, I lowered the CPU frequency to 80MHz, and the flash frequency to 40MHz. (Arduino defaulted to these being 240MHz and 80MHz, respectively.) I can now create, edit, and move files successfully, and rebooting the device via the button no longer produces "unable to initialize SD card" errors.

from runcpm.

After Adafruit's fork of SDFAT being mentioned in issue #106 I dedusted a Lolin32-Pro to try this lib instead of the picky SDFAT/original.

And it works!   \o/

I could rebuild SPL with its libs and demos (MAKESPL.SUB) again which already failed at the fist disk write accesses with SDFAT/original with all my SD cards.

Because the SDFAT/original doesn't work for me, I cannot make speed comparisons. IIRC with the lib in use before switching to SDFAT/original it lasted much over an hour (that's all I remember now) and with SDFAT/Adafruit 15±ε minutes.

As it doesn't need fiddling in a library's header file, maybe switching to this one is a good idea for everyone?

from runcpm.