Odd printf behaviour

[JBM]

Nothing new about the subject, to be fair, but this one isn't to do with mis-printing of floating point numbers or the like.

I have a piece of code which only works when the printf() statements are in place, and just hangs when they are commented out. PCH ver. 3.249

[PCM programmer]

Printf inserts a delay. One thing you might do as a test, is comment
out the printfs and insert delay_ms() statements in there instead.
I don't know what baud rate you're using, but at 9600 baud, one
character takes about 1 ms. So if your printf statement displays
four chars, plus a carriage-return linefeed, then put in delay_ms(6).
See if that also makes it work.

One fine point is that if the UART Tx buffer is empty, then the first
two chars won't take up any time. So if you sent six bytes it would
really only take 4 ms. But just for the purposes of this test you might
as well delay for the full amount.

[JBM]

Well, your suggestion worked PCM Programmer, but I don't understand why a delay (of any length) would alter matters here (though it clearly does). I'm not waiting for I/O and I'm not causing any side effects by calling a delay, yet it only works with the delay.

One point I didn't mention last night when I posted was that when the file contents spanned across multiple sectors on the MMC, all the data from a fully used sector worked fine, but only runs into this problem if the sector wasn't fully used (i.e., the final sector is where the problem is).

Thanks for your help so far - any more suggestions?

-JBM

[PCM programmer]

If it works when a delay is added, it implies that some hardware process
is in progress and that it takes time for it to be completed. It implies
that possibly, there is a status bit that could be checked to determine
if the hardware process is complete, but that currently there's no code
in there to check that bit.

The fact that it happens on a partial sector which is also the last sector
is a clue. That brings to mind two possibilities:

1. Perhaps the MMC device doesn't really write just the few bytes
in a partial sector. What if it really writes all the bytes, including
the unused ones ? What if, for some reason, you're not checking
a status bit to tell when the last sector is completely written ?

2. What if, after you write the last sector, the MMC device has to go
through some internal process to update pointers, etc., and this
process takes a certain amount of time to complete ? Is it possible
that there's a status flag that can be checked ? Is it possible that
the function that you're calling in the driver does return such a
value, but that your code ignores it ?

[JBM]

This particular implementation has been designed to hopefully aviod such problems. By that I mean that it reads in the entire 512 byte block to to a RAM buffer, and fgetch() simply decides whether or not the RAM buffer is empty or not - if it is, it requests the next block (and it always reads in 512 bytes, even if the whole block isn't necessarily used up). If the buffer isn't empty yet, then it simply reads the character out of the buffer.

To check this, a few days ago I modified the read_sector() funtion so that after reading a sector, it would print out the full contents of the RAM is saved the secor to. It worked flawlessly every time. I then compared this behaviour to the fgetch() behavior. The sector was being read corrently (and printed out to verify this), but when I came to access the data via the fgetch funtion, it didn't necessarily work.

As far as I can see, the problem was with my RS232 printing out (see above, the bit I edited).

Thanks for your input
-JBM