SPI / LCD Bug?

[xupz]

I posted before regarding the SPI / LCD interfacing, but I have that working now. I have run into a curious issue however.

If I run the code from CodeWarrior debug via Multilink, the LCD works as it should, instructions and commands work using the USB to debug/power it. If I disconnect the USB and add an external power source and power up (jumper pin on mcu project board to pwr_sel), the 9S12C32 and LCD will power up as normal, but the LCD will no longer execute. I have also verified that the 595 shift register is no longer receiving the MOSI inputs from the SPIDR. I have a significantly large enough delay prior to execution of the code to allow for powering time, so for some reason the SPI appears to not function as it should when changing from USB/debug to external power.

Has anyone run into this problem? I'm not sure what's different from running the codewarrior debug vs the microcontroller on external power. Any help in pinpointing the problem would be much appreciated.

[Lundin]

There could be several causes, here are some likely ones:

- Writing to write-once registers several times. Such as INITRM, INITRG etc.

- Missing pull-up on the reset line.

- Missing pull-up on the BKGD line.

- Missing 0V on the MODA / MODB pins.

- Incorrect decoupling cap value on the reset line (use approx 100pF).

- Clock issues.

[xupz]

Thanks for the reply, but I found the problem.

When the microcontroller is connected via the MCU project board and run from CodeWarrior, CodeWarrior reads the SPISR and resets the SPIF. However, when you remove the microcontroller and run it off an external source, the SPISR_SPIF should be zero on power on/reset, but it's not. Prior to intializing the SPI registers, I added:

volatile unsigned char status;

SPISR = status;

to clear the SPIF by reading the SPISR register (

I'm not sure if it's a hardware logic bug on reset, or something I overlooked in the reference manual, but those two lines of code solved the SPI problem. I hope that helps someone else out.

[xupz]

typo correction:

volatile unsigned char status;

status = SPISR;

[bigmac]

Hello,

It seems that this is a SPI issue that is common to both 16-bit and 8-bit devices, requiring an initial read of the status register after enabling the SPI module, and before attempting to write the first byte to the data register.  When the BDM was operative, it is possible that this was providing the necessary initial status register read.

The issue might be tackled in either of two ways -

1. To simply read the status register as part of the SPI initialisation.  The code
     (void)SPISR;  should also achieve the desired read.
2. Prior to sending each SPI byte, checking that the SPTEF flag is set will also provide the initial read.
     while (!SPISR_SPTEF);

Regards,

Mac