[samc] SPI setup clock sort of, no data

[Simon]

Well I have spent some time looking at the SERCOM in SPI mode. I set all my code up and am just trying to repeatedly spit some data out into an oscilloscope. I have a clock signal but it looks like it is appreciatively couple as all i see are +/- 400mV spikes with a curve back to 0. If I alter the baud rate the frequency of the spike changes to the new correct setting so that is the clock but it is not coming out.

According to the datasheet the pins direction is set by the peripheral, all I have to do in the port registers is turn control of the pin over to the SERCOM peripheral.

I have tried toggling the pins and no they won't toggle once I turn the pins over to the SERCOM so it is taking over.

I am using the explained board. according to the manual the SERCOM1 pins are uncommited.

[ataradov]

This looks like AC coupling somewhere, may be a broken probe. Does it show correct waveform if you probe scope calibration signal?

Also, why is there so much noise? I would be very worried if I saw something like that.

[Simon]

that is 200mV/Div, the probing is not teriffic with ground loops. the ground for that pin is at the other end of the header. I did get it cleaner at one point. I can change over to port control and get a 5V output with some ring on it.

[ataradov]

Show your code, I guess. This is not really normal, and I'm not sure how SAM C can produce anything like this even if intentionally misconfigured.

Does it behave the same way with data lines?

Check that you have correctly set DIPO and DOPO values.

[Simon]

this is just toggling the pin

[ataradov]

Let's see the code and what pins were expected to be SPI.

[Simon]

Code: [Select]

int main(void)
{
    /* Initialize the SAM system */
    SystemInit();
/* my initialization */

CLK_GEN_setup(2, CLKSRC_OSC48M | CLKDIV(100));

/* SERCOM1 setup */
pins_function(PORTA, (1111 << 16), FUNC_SERCOM );
SERCOM1_CLK_EN(2);
SERCOM_SYNC_baud(1, 100, 40000);
SERCOM_SPI_CTRLA_setup(1, (SPI_DATA_IN_PAD(0) | SPI_DATA_OUT_PAD(2) | SPI_MASTER | SPI_ENABLE | SPI_MASTER_MODE));




    while (1)
    {
SERCOM_SPI_8b_write(1, 0b01010101);
while(!SERCOM_SPI_INTFLG_read(1));


    }
}

I guess not the most useful as you will need to see the rest in the header files.

[Simon]

Code: [Select]

  SERCOM_SPI_CTRLA_setup(SERCOMn, MASK); */

/* data order */
#define SPI_data_order_MSB (0 << 30) /* default */
#define SPI_data_order_LSB (1 << 30)

/* SPI mode */
#define SPI_MASTER_MODE (3 << 28)
#define SPI_SLAVE_MODE  (2 << 28)

/* SPI frame format */
#define SPI_STD_FRAME (0 << 24) /* default */
#define SPI_ADD_FRAME (2 << 24)

/* SPI  data in pad */
#define SPI_DATA_IN_PAD(x) (x << 20) /* "x" to be 0-3 */

/* SPI data out pad */
#define SPI_DATA_OUT_PAD(x) (x << 16) /* "x" to be 0-3 */

/* Master / Slave mode */
#define SPI_SLAVE  (2 << 2)
#define SPI_MASTER (3 << 2)

/* SPI en/disable */
#define SPI_ENABLE (1 << 1)
#define SPI_DISABLE (0 << 1) /* default */

/* RESET */
#define SPI_RESET 1


static inline void SERCOM_SPI_CTRLA_setup(uint8_t SERCOMn, uint32_t mask){
( * ( volatile uint32_t * )( SERCOM_BASE + SERCOMn * SERCOM_OS + SERCOM_CTRLA)) = mask;
}


[Simon]

that is 200mV/Div, the probing is not teriffic with ground loops.

@ataradov pointed you to AC or DC coupling of your scope channel. Could you confirm that scope channel you are using to check said SPI clock signal is in "DC coupling" mode? Next time make sure to show relevant info in the menu as well. We are not interested in language and sound settings of your scope (friendly grin). Other possible cause of strange clock waveform - did you put series decoupling capacitor in your SPI clock line?

Yes the channels are in DC, the picture in post 4 is the same setup save for a change in V/div and s/div, as you can see it gets a pin toggle just fine. I had to go looking for the clock signal.

[ataradov]

Yeah, you are probably on your own with the custom header files.

The only thing that stands out right away is "(1111 << 16)". But who knows what that supposed to do.

[ogden]

The only thing that stands out right away is "(1111 << 16)". But who knows what that supposed to do.

This (X << Y) is still a thing in Atmel header files? 

[Simon]

Yeah, you are probably on your own with the custom header files.

The only thing that stands out right away is "(1111 << 16)". But who knows what that supposed to do.

that is the 4 pins that the SERCOM1 connects to. they are 16, 17, 18, 19. That bit of code is verified to work as once used the pin cannot be toggled so the port function is being switched over which is verified by the SPI clock sort of appearing.

I'll recheck the pins.

This is the function that sets up the pins multiplexer:

Code: [Select]

static inline void pins_function(uint8_t port , uint32_t pin_mask , uint8_t function ){ /* pins_function(port , pin_mask, function ); */

(*(volatile uint32_t *)(PORT_BASE + PORT_WRCONFIG + port * PORT_OFFSET)) = (pin_mask & 0x0000FFFF) | 0x1 << 30 | 0x1 << 28 | function << 24 | 0x1 << 16 ;
(*(volatile uint32_t *)(PORT_BASE + PORT_WRCONFIG + port * PORT_OFFSET)) = (pin_mask >> 16)        | 0x1 << 30 | 0x1 << 28 | function << 24 | 0x1 << 16 | 0x1 << 31 ;
}


[ataradov]

This (X << Y) is still a thing in Atmel header files? 

This has nothing to do with Atmel.

Also, what is wrong with shifts if done correctly?

[Simon]

The only thing that stands out right away is "(1111 << 16)". But who knows what that supposed to do.

This (X << Y) is still a thing in Atmel header files? 

No that is mine. How would you do it? i am sorry but i cannot remember off the top of my head each hex equivalent for every pin position not to mention the over 4 billion combinations in Hex of any pin mask not to mention in decimal either. i need to write code I can read back to myself without using a calculator.

[ataradov]

that is the 4 pins that the SERCOM1 connects to. they are 16, 17, 18, 19.

Would not it be "(0b1111 << 16)" in that case?

[Simon]

Yea, thanks a bunch atmel/microchip:

the data out pad can only be 3 of the 4 so the number put into the register is nothing to do with the pad number unlike the data in.

[Simon]

that is the 4 pins that the SERCOM1 connects to. they are 16, 17, 18, 19.

Would not it be "(0b1111 << 16)" in that case?

whoops, yes indeed, in addition to the fact that i have the wrong data out pad, so yes capacitive coupling.

[ataradov]

The amount of multiplexing those devices allow already far exceeds any other devices. Multiplexing inputs is very easy and cheap. Multiplexing outputs is expensive in silicon area and timing.

[Simon]

Yea, I just assumed that the out pad followed the same scheme as the in pad. I now have a clock and a data signal as expected.

Thank you.

[ogden]

This (X << Y) is still a thing in Atmel header files? 

This has nothing to do with Atmel.

AFAIK Atmel came-up with bit shifts in headers for AVR while most other MCU manufacturers used just plain hex for bitfields. Yes it is just matter of preference. In case of single bit definitions it does not matter that much which notation you use, but as soon as you approach something like (15<<4 | 4<<15), I would rather look at it in hex.

[ataradov]

But you never have to look at those shifts. If you are using defines, then you will never see them.

And shifts are self documenting if you actually need to figure it out.

I'd rather see "#define SOME_REG_VALUE (4 << 15)" than "#define SOME_REG_VALUE 0x20000". With the first one you clearly see that it was the value 4 at offset 15. The second one could be interpreted many ways.

[Simon]

This (X << Y) is still a thing in Atmel header files? 

This has nothing to do with Atmel.

AFAIK Atmel came-up with bit shifts in headers for AVR while most other MCU manufacturers used just plain hex for bitfields. Yes it is just matter of preference. In case of single bit definitions it does not matter that much which notation you use, but as soon as you approach something like (15<<4 | 4<<15), I would rather look at it in hex.

But your hex number will not mean much unless you commit all of the combinations to memory. I am rather poor on the memory side so make my code as self documenting as possible. I have a series of defines for each pin mask so i would just write PIN14|PIN15, I have also setup defines for all pins in the PA14 style that would translate into "0, 1<<14" this goes straight into any of the many low level functions I have as two variables for things like pin direction and setting or clearing a pin. This way the code is totally readable. If i want to build a multipin mask I just use PORTx, PINxx|PINxx|PINxx...... so that the code is totally readable.

[ogden]

But your hex number will not mean much unless you commit all of the combinations to memory.

When you look at memory or register contents in the debugger what you see - fancy bit shifts or hex numbers?

But you never have to look at those shifts.

Exactly. You define bit shifts but look at hex numbers, have to waste your mind power to process between two.

[ataradov]

When you look at memory or register contents in the debugger what you see - fancy bit shifts or hex numbers?

If you have a decent debugger, you see bit fields with names and values.

And I guess it depends on the use. I personally spend more time writing and reading the code than debugging, so I would always prefer something that lets me read and write easily.

And in a tightly packed register you still have to do manipulations to extract value. How would you easily know the value of 5-bit field at offset 15 in a hex value 0xabcdef12? Still need to mentally shift and mask things out.

[Simon]

Yes, I don't mind using hex values as reported on the datasheet for register locations. I may use easier hex values where appropriate like 0xFF but at bit level in a 32 bit word it has to be constructed out of something readable.