fix: reduce file system corruption from standalone Lua scripts

[3djc]

This possibly fixes LUA sd corruption. This PR is raised to allow easier testing

While at it, use more sdio_check_card_state_with_timeout();

Finding by @philmoz

This fixes #5077

[frankiearzu]

@3djc should we add the check also when the buffer is not aligned on reads??? The code before the HAL change had the check on both. The write has it on both (aligned and not aligned buffers)
Another option is to move that code inside the read_dma, and write_dma to not have that much code duplications.

Another difference with the "pre-hal" code is that that the disk status check (check the TRANSFER STATUS) is done if the read/write waiting for completion fails (currently we do only if succeeds).. the current code is short-cutting to "return" exit if the read/write waiting times out (failed).
Probably on "Fail" is more important to check the status.

Other difference is the transfer status on the original code is in an infinite loop until succeed or fail the transfer (not time out), new code is with a timeout. should we use the version of the sdio_check_card.. without a timeout??

From the original HAL ticket: (also seems that all that code should be inside the read_dma/write_dma).

Tried my proposed changes on my local branch and works, but did not solve the original problem with the LOGS corruption, but everything still works the same as before.

[frankiearzu]

On my local branch, i move the transfer check to inside the read_dma/write_dma:

1. Replicated the original logic... the transfer wait is done if the waiting for read/write completed timeout (as in the pre-hal code). No shorcut exit.
2. Loop without timeout... until the transfer either succeed or failed.
3. Removed the transfer checks from read/write since now that logic is inside read_dma/write_dma.. removing many cut/paste parts of the same code.

[raphaelcoeffic]

but did not solve the original problem with the LOGS corruption

Assuming that this PR "fixes" (actually, it masks it, but well) the original issue, I don't think adding all the clutter back is gonna help anyone here.

[frankiearzu]

@raphaelcoeffic agreed... this probably just make it harder to reproduce, but is not the fix to the root cause problem.
Will do a proposed change on the timing of the DMA (proposed on the other ticket), but haven't had time to test (workdays :-)

[raphaelcoeffic]

Frankly, I'm still not convinced the SD block layer is at fault. Everything points at the way we use FatFs, and FatFs behaviour.

[richardclli]

@raphaelcoeffic agreed... this probably just make it harder to reproduce, but is not the fix to the root cause problem. Will do a proposed change on the timing of the DMA (proposed on the other ticket), but haven't had time to test (workdays :-)

You can do a quick test to lower the SDIO speed by changing a line, if it still fails, then it is not about DMA timing anyway.

[frankiearzu]

@richardclli I did lower the timing and still failed. I think probably put this to rest until we get others to report a similar problem.
DSM forward prog seems to produce the error really quick,, more repetitions with other LUA scripts. Changed the forward programming script to stop writing to the logs in the meantime.