The hardware problem doesn't explain his statement:



This wouldn't happen with a hard-stuck address line, would it? If so, the simulation using data type int should have revealed why as well, shouldn't it?

Since we don't have physical evidence, we can't claim it's faulty construction technique, and since we don't have evidence, we can't claim it's defective components.

If he had an oscilloscope, he'd already have seen that the LSB of the low address byte doesn't change at the correct rate if that were the case. If he had a single-step circuit, he'd have measured address line voltages in a static state and found the fault in that way. However, the problem he states is associated, in some way, with the HLL he's using. If we had a look at the ASM output from his compiler, that might shed some light. The 'C' code will only be helpful to someone who knows exactly what the MCU will do in response to it. One possible explanation for the correct result using int and the incorrect one using char is a stuck address line. One possible explanation is that, using int, it would write two bytes to the SRAM, isn't that right? It's unclear how he's handled the writes to SBUF when he's using int data type.

That's why I think it should be examined using ASM and not 'C'.

I'm questioning, not the conclusion, but, rather, the method in attaining it. I think one should remove all the factors that introduce ambiguity. The HLL compiler potentially is one such factor.

RE