hbios - PPIDE file copy about romwbw

[feilipu]

The issue started just with PPIDE, but actually I could get it to affect everything during testing.

SDCC is quite unpredictable where it puts stuff on the stack. Even changing the optimisation pressure can have a major effect on how the stack is managed. So initially I was getting reboots only with PPIDE, then failures just with PPIDE, then failures (depending on unknown stuff) everywhere.

I guess it just depended whether the specific stack position at the pointer address was being clobbered by another thing. The SD driver would certainly be using the stack differently, and that may have been the cause of the differing symptoms. But, I can't really tell.

[wwarthen]

Surprising. Nothing occurs to me right off. It is certainly possible there was a regression in my code. I will do some regression testing today.

-Wayne

[wwarthen]

I tried to recreate this issue using my SC126 and a PPIDE adapter. I used my FAT application under CP/M for testing just because I could do it quickly. The FAT application is based on FatFS. I had no problem repeatedly copying files to/from the FAT filesystem. Also no problem just copying from and to the FAT filesystem in a single operation. I did this with a 1MB file and tried repeatedly with no issues.

In the end, this doesn't mean too much because there are so many edge cases that are hard to take into account.

• When your system restarts during a copy operation, does it do so near the start, middle, or end of the copy process?

• I don't see anything strange in your code. It is substantially similar to the functions I use in the FAT application.

• I note that you are using a much larger CF Card than I am. Not sure why that would matter though.

• You are running under the debug monitor and I am running under CP/M. However, there are literally no CP/M calls involved when FAT.COM copies a file to & from the FAT partition.

I will think about this some more. Not immediately sure what to try next.

-Wayne

[feilipu]

Thanks for checking, Wayne.

I'll have to try breaking it down further to get a result.
Try some repeated reads, and repeated writes, perhaps.

I tried using the RC2014 last night too, with the same +hbios target code. The result is similar, but there is no reboot. Instead it creates the file (with 0 bytes), and returns to dbgmon instead of copying.

The only "dog-walk thought" that occurred was there is something odd in my timer functions. They are being called directly before the copy action, so a fault there would result in a similar symptom.

[wwarthen]

It occurred to me that I should try the FatFS I/O test module on a PPIDE device. I did this and it passed all tests repeatedly. I am still stumped. I hope you can find something.

-Wayne

[feilipu]

I've done a little more back to back testing, and seen the following.

• The reset issue has gone away.
  Must have been doing something stupid, but the copy program is not working.
• My simple mount-open-write-read test program works perfectly fine.
• Sometimes, the copy loop errors out on the first write, leaving one buffer full of data correctly written to the file.
• Mostly, the copy loop errors out on the first read, leaving 0 bytes copied.

Every time, the error is the same INVAILID_OBJECT. This error is generated (potentially) by the validate() function, if the drive is not properly initialised (correct is return 0).

I am concerned that simply calling BF_DIOSTATUS for disk_status() may not be giving the expected 0 answer, if the drive is busy?

Otherwise, further work on this tonight.

Can only find one location where PPIDE_STAT is set, and this doesn't seem to depend on whether the drive is busy or not. Odd.

[wwarthen]

In theory, the only way that DIOSTATUS will return a non-zero result is if a prior I/O request failed. However, if that happened, you would have gotten an error from the I/O call itself. Sorry I don't have any ideas.

-Wayne

[feilipu]

OK. Kind of a learning experience.
The issue was nothing at all to do with what I suspected.

f_mount() requires a pointer to a FATFS filesystem object.
Feeding it the address of a filesystem object is not sufficient.
That is one degree of abstraction too few, and boom, the filesystem object is invalid, so we get the error above.

Explains why my simple program worked properly (because it used malloc() to allocate a FATFS filesystem object) but my copy program didn't do this (it just provided the address of a bss allocated filesystem object), and so it failed as the pointer containing the address filesystem object was just pushed onto the stack, and was later discarded.

Sorry for being thick.

[wwarthen]

Ah, that does explain it. Glad you got it resolved! Kind of surprised it was only affecting things when the PPIDE driver was being used, but I have seen stranger things.