http://home.arcor.de/luka5/open/SPI_01.GIF

You can see the data send througt the TxD line (2. in picture): 0x8000

I am wondering why there is a "ONE" at LSB´s position because I am writing 0x00 to the u3tbgl register twice..

1.RxD

2.TxD

3.!CS

4.Clock

No matter what I do, there always a "ONE" at the firts postition.

When I do this:

    CS = 0;
    te_u3 = 1;
    while( !ti_u3);
    u3tbl = 0xFF;    // <--- first 8 bits
    while( !ti_u3);
    while( !txept_u3);
    u3tbl = 0x00;    // <--- last 8 bits
    while( !ti_u3);
    while( !txept_u3);
    re_u3 = 0;
    te_u3 = 0;
    ckpol_u3 = 1;
    CS = 1;
    ckpol_u3 = 0;

I get this at the TxD line: 0xFF80;

It seems that first a "ONE" is send, then the 0xFF and finally this: 0b0000000 (7 bits only)

The result of that 16-bit write: u3tb = 0x0000;

is the following: 0x80; at TxD  (only 8 clocks)

If I write: u3tb = 0xFFF0:

result is: 0xF8; (only 8 clocks)

It seems, to me that there is always a "ONE" shifted in.

This is how I have set up the SPI mode:

     u3smr  = 0x00; // No I2C Mode
     
     u3smr2 = 0x00;
     
     u3smr3 = 0x00;  // SS Port function.. ??
     
     u3smr4 = 0x00;
     
     u3mr  = 0x01;  // SPI MODE, Internal Clock
     
     u3c0  = 0x92;  // Data on falling edge, f32 as clock source, no CTS, CMOS output
     
     u3c1  = 0x00; // rx,tx disabled
     
     u3brg = 0xff;   // (Takt UART3) very slow..

I am using a m30245fcgp.

There is no application note on SPI for this µC nor even for this family: M16C/24

I have found some document describling the SPI for a M16C/6P i think, I am not sure about that type.

The SPI hardware should be the same as for the M16C/24. Someone here wrote it.

Nethertheless the datasheet should be enough to configure the SPI mode..

What do You mean by: "set the registers manually" ?

Are You thinking of using a debugger or rather to set them by using a constant like: t3bgl = 0x12; for example...

Ok. Here I am again with that issue..

Using the Hardware SPI with a M16C24 (M30245FCGP) I observed strange behaviour.

void SPI3_init( void) 
{
     pd2_3     = OUT;          // ADC_CD is OUT
     pd7_6   = OUT;          // ADC_CLK is OUT
     pd7_5   = IN;          // ADC_DOUT
     pd7_4     = OUT;          // ADC_DIN
     
     ADC_CS  = HIGH;          // ADC communication disabled [ Chip Select]

     u3c0    =  0xD1;         // MSB first, falling edge, CTS disabled, internal Clock f8 (2MHz)
     u3c1    =  0x00;         //
     u3brg   =  1999;         // divide f8 by 2000
     u3c0   &= ~0x20;
     u3smr3 &= ~0x02;
     u3mr     =  0x01;
     
     ckpol_u3 = 0;          // transmit data is output at falling edge, recieve data is input at rising edge of clk
          
}

The code above should normally configure uart3 to transmit data at falling clk edge.

What I am observing is the opposite.

In the following scope screenshot one can see, that data is output at rising edge. (I am writing: 0b0101 0101 0000 1111)

http://home.arcor.de/luka5/open/M16CSPI/ckpol-0.jpg

And here a zoom in at the first falling edge where data should be: 0

http://home.arcor.de/luka5/open/M16CSPI/ckpol-0_b.jpg

In best case both transitions, DATA and CLK occur simultanously. This results in a undefined state.

In worst case CLK falls when DATA is still HIGH.

My reciever (a ADC) has a DIN set-up time prior to SCLK falling edge of min. 4ns.

And a DIN hold time after SCLK falling edge of min. 2ns

Now I show you a screenshot with ckpol_u3 = 1; [The datasheet says: if ckpol_u3 = 1, Transmit data is output at rising edge, recieve data ist input at falling edge of clk]

http://home.arcor.de/luka5/open/M16CSPI/ckpol-1.jpg

Zoom in of the first rising edge:

http://home.arcor.de/luka5/open/M16CSPI/ckpol-1_b.jpg

In my opinion this is a transmission on rising edge not on falling edge.

What do you think about it?

Regards

  luke