The example program msc1200_adc works in the simulator, but does not appear to run on the msc1200evm hardware. If the Ouput -> Run User Program box is checked and the name of the download is corrected to match the name of the executable, the program downloads and starts to run, but the characters in the terminal window are gibberish. The code appears to use 2400 & 8bits, but setting the terminal to these values does not fix it. Does this example work on the real hardware or just the simulator?
I'm not familiar with your derivative, but some have SFR bits that control what physical memory space is mapped into the xdata addressing range. Could this be your problem?
I'll look at the SFR as you suggest, but I've found a curious result that makes me suspect the compiler has issues with xdata arrays. The following prints '8' in both printf statements as expected. =========== works =========== int xdata dd[10]; i = 8; z = dd[8] = i; printf("dd[8] = %d\n", dd[8]); printf("z = %d\n", z); =========== but the following prints '-1' in both print statements. This should be equivalent to the preceding code snippet (right?). =========== fails =========== int xdata dd[10]; i = 8; dd[8] = i; z = dd[8]; // <=== hmmm? printf("dd[8] = %d\n", dd[8]); printf("z = %d\n", z); ===========
I'll look at the SFR as you suggest I do not know your derivative, but all I know need some bit (re)set in a SFR to access internal XRAM. but the following prints '-1' in both print statements. This should be equivalent to the preceding code snippet (right?). printing ff usually means that the hardware does not read the external memory. Erik
That appears to be the problem. Under CKCON it says "Since the MSC1200 does not allow external memory access, these bits should be set to 000B to allow for the fastest flash data memory access." That sounds pretty conclusive. The MCS1200EVM has 32KB on it but this memory is connected to the I2C port rather than being connected as flash memory. Something else to investigate..... Thanks for your help.
"I'll look at the SFR as you suggest, but I've found a curious result that makes me suspect the compiler has issues with xdata arrays." It's always tempting to blame the compiler but I'm afraid to say the Keil tools are rather good. It's rare to discover it isn't your own mistake... "The following prints '8' in both printf statements as expected." I think the optimiser has cheated you out of the read from the array. I suspect that if you change the first line to: int volatile xdata dd[10]; the first code snippet will also fail.