topic Re: Avoiding the new initial status read before using the S08 SPI in 8-bit Microcontrollers

Avoiding the new initial status read before using the S08 SPI

peg — Mon, 09 Jul 2007 17:59:39 GMT

Hi,

Starting with the S08 there is a new restriction that requires you to read the SPI status register to test for transmit buffer empty before you write to the data register.

It was not necessary with the older HC08/05's

This issue has been discussed before here:

http://forums.freescale.com/freescale/board/message?board.id=8BITCOMM&message.id=5009

In that post I suggested to test the SPTEF bit in the SPIS on every write as this is how I had converted a HC908GP32 project into a GT16. I came up against this problem again (converting GP32 code to GT16A) This time the SPI is much busier, previously it was only used on initialisation and manual test read.

It is really only necessary to do this before the first ever read as the check for SPRF during the transmit/recieve will cover the requirement on subsequent uses.

I found the best way to achieve this is to do a read of the SPIS right when you setup the SPI, like this:

Code:

*********** Setup SPI for EEPROM ********************************************  MOV #(mSPE|mMSTR),SPIC1 ;Enable SPI as master 0,0  CLR SPIC2  MOV #mSPR0,SPIBR  ;/4 = 5MHz  LDA SPIS   ;dummy SPTEF check

This way you can use a normal SPI send/recieve routine like this:

Code:

OUTBYTE         STA SPID             ;put data in SPI register                BRCLR SPRF,SPIS,*  ;wait till sent (or recieved)                LDA SPID             ;read returned value                RTS

This avoids the unecessary check of SPTEF every time while keeping things where they should be found.

Re: Avoiding the new initial status read before using the S08 SPI

bigmac — Mon, 09 Jul 2007 23:35:27 GMT

Hello Peg,

Thank you for a timely reminder . . . I had completely forgotten about that one.

Fortunately, when I have previously suggested SPI code on this forum, I normally include the extra test of SPTEF, with the consequent penalty of 5 cycles for HCS08. But at least it means the function will always work on whatever MCU, without the need to be particularly concerned about the process of SPI initialisation.

Perhaps this is appropriate for the forum, since the few additional cycles are probably inconsequential for most projects.

Regards,

Mac

Re: Avoiding the new initial status read before using the S08 SPI

Unknown — Wed, 28 Jan 2009 21:42:32 GMT

Hello Bigmac,

I am working on SPI Driver for MC9S08DZ60 microcontroller. I have one master and one slave, both master and slave are of same microcontrollers( MC9S08DZ60). I have a problem in receiving a byte at the slave side. Im not sure also whether the data byte has been sent or not. Following is my code.

Transmit function at Master side:
---------------------------------------

void spi_tx(void)
{
    int fl_dummy;;
    while(!SPIS_SPTEF);
    fl_dummy = SPIS;                //Clear SPTEF flag
    SPID = 0x06;
    while((SPIS & 0x80) != 0x80);   //Wait for transmission to complete
}

Receive function at Slave side:
---------------------------------------

int spi_rx(void)
{
   int temp;
   temp = SPIS;
   while((SPIS & 0x80) != 0x80);
   temp = SPID;
   return temp;
}

This micro controller is from HCS08 family.

Can u please lemme knw what and where the prblm exists.
Its very urgent. Kindly reply me ASAP.
Thank you.

Regards
xxxx

Re: Avoiding the new initial status read before using the S08 SPI

peg — Thu, 29 Jan 2009 06:36:28 GMT

Hi Unknown,

Does your transmit routine hang?
If not, your data is sent!

Does your receive routine hang?
If not, what is wrong with the data that you're getting?

How have you initialised each SPI module?

Re: Avoiding the new initial status read before using the S08 SPI

Unknown — Thu, 29 Jan 2009 14:40:08 GMT

Hi Peg,

When i run the code at one shot without any brkpoints(at master side) it will come out of transmit function, it does not hang. But when I run step by step by putting break points it will never come out of the below line.

<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><meta name="ProgId" content="Word.Document"><meta name="Generator" content="Microsoft Word 11"><meta name="Originator" content="Microsoft Word 11">ection1;} --> while((SPIS & 0x80) != 0x80); (in Transmit function)

Im using CRO to test the same. I hav connected 4 probes to 4 corresponding pins of master(No connections between master and slave at this point). But im not able to see the data on the bus.

When I run at one shot then the execution hangs at the receive function (Slave side),at the below line
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><meta name="ProgId" content="Word.Document"><meta name="Generator" content="Microsoft Word 11"><meta name="Originator" content="Microsoft Word 11">ection1;} -->

while((SPIS & 0x80) != 0x80); (in receive function).

So kindly let me know the prblm.

Regards

xxx.

Re: Avoiding the new initial status read before using the S08 SPI

Unknown — Thu, 29 Jan 2009 14:45:44 GMT

ection1;} --> while((SPIS & 0x80) != 0x80); (in Transmit function)

Im using CRO to test the same. I hav connected 4 probes to 4 corresponding pins of master(No connections between master and slave at this point). But im not able to see the data on the bus.

When I run at one shot then the execution hangs at the receive function (Slave side),at the below line
ection1;} -->

while((SPIS & 0x80) != 0x80); (in receive function).

Yes I have initialised the SPI modules at both sides. Below is the code.

Master Side:

-------------

void spi_init(void)
{
   SPIC1 = 0x74;
   SPIC2 = 0x00;
   SPIBR = 0x00; //4MHz: Half of the bus clock(8MHz)
}

Slave Side:

-----------

void spi_init(void)
{
SPIC1 = 0x44;
SPIC2 = 0x00;
}

So kindly let me know the prblm.

Regards

xxx.

Re: Avoiding the new initial status read before using the S08 SPI

peg — Thu, 29 Jan 2009 17:10:42 GMT

Hello unknown,

You have master side transmit interrupts enabled but your transmit function does not look like an interrupt function. Even if it is, don't implement it as an interrupt just yet get it working first then do it as an interrupt later.
Change your master side init of SPIC1 to 0x54 and see how you go then.

Re: Avoiding the new initial status read before using the S08 SPI

Unknown — Thu, 29 Jan 2009 17:51:17 GMT

Hello Peg,

I have tried with SPIC1 = 0x54.
Even though its not working. I cannot see the data on the MOSI line in the CRO.
Im using polling method instead of interrupt.

I can see the SCLK on the bus, but not the data. I guess problem is in the transmit function.
But not sure where? could u pls help me out.

Regards
XXX.

Re: Avoiding the new initial status read before using the S08 SPI

peg — Thu, 29 Jan 2009 18:18:18 GMT

Hi,

Once you have the SPI initialised properly, transmitting is simply a matter of writing to the SCID. You only get activity on the SCLK line when data is being transmitted. If you don't see any activity on the data (at the same time you are seeing CLK's) you are sending a 0x00 or 0xFF or your hardware is broken.

If you go back to the assembly example at the top of the thread, this is all you need to send and recieve on SPI.

Re: Avoiding the new initial status read before using the S08 SPI

Unknown — Fri, 06 Feb 2009 15:40:08 GMT

Hi Peg,

Thanks a lot for the information.
SPI is working now.

Regards
xxxx

Re: Avoiding the new initial status read before using the S08 SPI

Thunder — Sat, 19 Dec 2009 02:36:48 GMT

Hi, I've read this thread a number of times as well as others in the forum pertaining to SPI on the HC9S08 products (I'm using the MC9S08LG32). Since the instuctions provided in this thread are clear, I am thinking whether my problem with SPI lies with CodeWarrior. I am interfacing the uP with an A/D converter (ADS1241). On this device the "POL" pin is tied to ground. I could not find info in the datasheet for phase, so I left this at 0. Here is my code:
SCGC2_SPI = 1; // System Clock Gating Control Register to enable clocking to SPI;
SPIC1 = 0x50; // Enable SPI interface and uP as Master
SPIC2 = 0x00;
SPIBR = 0x45;
dummy = SPIS; // Read SPIS
PTED_PTED5 = 0; // PTE5 is GPIO to enable device
//
SPID = 0x11; // Send first data byte (instruction to A/D)
while (!SPIS_SPRF); // Wait for SPRF to load
dummy = SPID; // Read SPID
SPID = 0x01; // Send 2nd data byte (2nd part of instruction)
while (!SPIS_SPRF); // Wait again
dummy = SPID; // Read SPID (no info should be here)
SPID = 0xff; // Send dummy byte to A/D
while (!SPIS_SPRF); // Wait again
dummy = SPID; // Should be real feedback here

Using CodeWarrior, I look at the SPID in the memory window. In continually reads 0xFF. When I single step thru the code, the program hangs on the while statements. Running the code full-speed works fine; however, I still get only FF as a response from the A/D (looking at SPID and the variable dummy in the memory window of CW). Any comments would be appreciated.

Re: Avoiding the new initial status read before using the S08 SPI

Thunder — Sat, 19 Dec 2009 04:35:25 GMT

Hi again, it seems to have been a HW problem (my MISO line wasn't even connected to the A/D device). After soldering in a jumper, it seems to be working. Still curious though why the read response would be 0xFF each time.

Re: Avoiding the new initial status read before using the S08 SPI

peg — Sat, 19 Dec 2009 04:55:02 GMT

Hello Thunder and welcome to the fora.

The SPI simply clocks in the level present on the MISO pin at the appropriate clock transition. If an unconnected pin happens to assume a high level, you will see 0xFF as the byte clocked in. No mystery here!

Re: Avoiding the new initial status read before using the S08 SPI

peg — Wed, 17 Mar 2010 17:12:57 GMT

Hmmmm.....

I just got caught by this again. Doing another conversion from GP32 to GT16A.

I was using the debugger to find another issue and this caused the problem not to occur. Only when I went back to standalone running did it hang due to the failure to read the status register first. On the debugger it runs OK. The debugger was not displaying the status register at the time so I do not know why the debugger "fixes" the problem.