[samc] SPI setup clock sort of, no data - Page 1
Forum section: electronics / general

author: Simon
author_rank: Unknown
timestamp: April 10, 2020, 07:14:27 pm
content: 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.

author: ataradov
author_rank: Super Contributor
timestamp: April 10, 2020, 07:29:29 pm
content: 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.

author: Simon
author_rank: Unknown
timestamp: April 10, 2020, 07:34:49 pm
content: 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.

author: ataradov
author_rank: Super Contributor
timestamp: April 10, 2020, 07:38:00 pm
content: 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.

author: Simon
author_rank: Unknown
timestamp: April 10, 2020, 07:38:39 pm
content: this is just toggling the pin

author: ataradov
author_rank: Super Contributor
timestamp: April 10, 2020, 07:40:18 pm
content: Let's see the code and what pins were expected to be SPI.

author: Simon
author_rank: Unknown
timestamp: April 10, 2020, 07:42:25 pm
content: Code: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.

author: Simon
author_rank: Unknown
timestamp: April 10, 2020, 07:43:32 pm
content: Code: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 1static inline void SERCOM_SPI_CTRLA_setup(uint8_t SERCOMn, uint32_t mask){( * ( volatile uint32_t * )( SERCOM_BASE + SERCOMn * SERCOM_OS + SERCOM_CTRLA)) = mask;}

author: Simon
author_rank: Unknown
timestamp: April 10, 2020, 07:45:33 pm
content: Quote from: ogden on April 10, 2020, 07:43:32 pmYes 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.

author: ataradov
author_rank: Super Contributor
timestamp: April 10, 2020, 07:46:39 pm
content: 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.

author: ogden
author_rank: Super Contributor
timestamp: April 10, 2020, 07:53:24 pm
content: Quote from: ataradov on April 10, 2020, 07:46:39 pmThis (X << Y) is still a thing in Atmel header files?

author: Simon
author_rank: Unknown
timestamp: April 10, 2020, 07:54:09 pm
content: Quote from: ataradov on April 10, 2020, 07:46:39 pmthat 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: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 ;}

author: ataradov
author_rank: Super Contributor
timestamp: April 10, 2020, 07:54:45 pm
content: Quote from: ogden on April 10, 2020, 07:53:24 pmThis has nothing to do with Atmel.Also, what is wrong with shifts if done correctly?

author: Simon
author_rank: Unknown
timestamp: April 10, 2020, 07:56:05 pm
content: Quote from: ogden on April 10, 2020, 07:53:24 pmNo 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.

author: ataradov
author_rank: Super Contributor
timestamp: April 10, 2020, 07:56:11 pm
content: Quote from: Simon on April 10, 2020, 07:54:09 pmWould not it be "(0b1111 << 16)" in that case?

author: Simon
author_rank: Unknown
timestamp: April 10, 2020, 08:01:14 pm
content: 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.

author: Simon
author_rank: Unknown
timestamp: April 10, 2020, 08:02:48 pm
content: Quote from: ataradov on April 10, 2020, 07:56:11 pmwhoops, yes indeed, in addition to the fact that i have the wrong data out pad, so yes capacitive coupling.

author: ataradov
author_rank: Super Contributor
timestamp: April 10, 2020, 08:02:52 pm
content: 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.

author: Simon
author_rank: Unknown
timestamp: April 10, 2020, 08:10:55 pm
content: 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.

author: ogden
author_rank: Super Contributor
timestamp: April 10, 2020, 08:21:08 pm
content: Quote from: ataradov on April 10, 2020, 07:54:45 pmAFAIK 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.

author: ataradov
author_rank: Super Contributor
timestamp: April 10, 2020, 08:25:13 pm
content: 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.

author: Simon
author_rank: Unknown
timestamp: April 10, 2020, 08:27:27 pm
content: Quote from: ogden on April 10, 2020, 08:21:08 pmBut 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.

author: ogden
author_rank: Super Contributor
timestamp: April 10, 2020, 08:30:00 pm
content: Quote from: Simon on April 10, 2020, 08:27:27 pmWhen you look at memory or register contents in the debugger what you see - fancy bit shifts or hex numbers?Quote from: ataradov on April 10, 2020, 08:25:13 pmExactly. You define bit shifts but look at hex numbers, have to waste your mind power to process between two.

author: ataradov
author_rank: Super Contributor
timestamp: April 10, 2020, 08:31:47 pm
content: Quote from: ogden on April 10, 2020, 08:30:00 pmIf 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.

author: Simon
author_rank: Unknown
timestamp: April 10, 2020, 08:47:44 pm
content: 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.