SPI MC9S08QE128RM SPI

[jat]

SR Number:    1-606904445 I already open a technical request but until now the probelm still on

Date Opened:  16-Jan-2010 02:46:22 AM
Subject:      MC9S08QE128RM SPI
Description:
To whom it may concern.
We are using MC9S08QE128- 44 pin, with  two SPI.
We  want to control SS1 line as IO's due to we need to send two bytes to
a DAC., using the SPI as bidirectional only MOSI
The problem we have if the program run step by step SS2 line goes low
and high controlled as standard IO's. When the program run under
debugger the SS2 line is high never goes low
Here is the code that control the SPI
The code is attached to this email.
I need to know were is our mistake.
Regards
Jose Tello
Te: 604-299-5173

[jat]

Hi Mac

I did change the way I send data to SPI controlling SPIRF .

In my application I use two SPI one bidirectional only MOSI (DAC, Digital POT) and the another MISO and MOSI lines.

The problem is  in SP1 I can not pull down SS1 (PTB5 ) line when the code is running mode. When I run step by step the line goes down . Here is the initialization code .

Port Configure

#define PORTB_CONFIG()       PTBDD =   PTBDD_PTBDD5_MASK | PTBDD_PTBDD2_MASK|     PTBDD_PTBDD3_MASK;\ 

                             PTBD |= PTBDD_PTBDD5_MASK | PTBDD_PTBDD2_MASK| PTBDD_PTBDD3_MASK;       

#define DAC_CS_LOW()         PTBD_PTBD5 =0 ;
#define DAC_CS_HIGH()         PTBD_PTBD5 =1  ; 
 

           SPI1C1 = SPI1C1_SPE_MASK | SPI1C1_MSTR_MASK | SPI1C1_CPOL_MASK |             SPI1C1_CPHA_MASK;
           SPI1C2 = SPI1C2_SPC0_MASK | SPI1C2_BIDIROE_MASK;
           SPI1BR = 0x11;
      When the function is called with out Break Point  SS1 never goes to low. If thre function is executed step by step SS1 will goes low. I DO NOT KNOW WHY IS HAPPENING IT

DAC_Write(unsigned short ChanA, unsigned short ChanB)

{

 DAC_CS_LOW()   --------> SS1 Line 

  ......wrtite dat to SPI

 DAC_CS_HIGH()

}

Jose

[bigmac]

Hello Jose,

The initialisation of the SPI1 module appears to be correct, assuming the bit SOPT_SPI1PS = 0 to use the port B pins for the SPI.

However, PTB5 is alternatively used for TPM1CH1, which could override the GPIO control if other than software only interrupt mode is ever selected for this channel.  I have no other explanation for what you are observing.

It should not have any effect for the current problem, but I would tend to initialise PTB2 and PTB3 as inputs, with pullups enabled, applicable when the SPI module is disabled.  When the SPI module is selected as a master, these pins will then become outputs controlled by the SPI module.

Regards,

Mac

[bigmac]

Hello Jose, and welcome to the forum.

Within the code that you have posted, I cannot see where you are attempting to set SS2 low. Do you actually mean SS1 or SS2?

However, I do have a comment about your DAC_write() function. I notice that you are testing only the SPTEF flag, and have implemented a delay for the SPI transfer to complete.

Even though you have no interest in the MISO data, after each byte is sent it is still necessary to wait until the SPRF flag is set, and to then clear this flag by reading the SPID register. This approach will mean that the delay can be eliminated, since the transfer will already be complete when the flag becomes set. It will also prevent an overrun condition from occurring, and possible "latch up" of the SPI module.

The SPTEF flag is relatively unimportant, since it will always be set prior to each byte being sent.

When debugging the SPI code, it is possible that you may not be able to single step since the debugger itself may provide the conditions to clear the SPRF flag, resulting in the wait loop never exiting. Place a breakpoint after the wait loop for predictable operation.

Regards,

Mac

Message Edited by bigmac on 2010-01-20 03:07 PM