SPI initialization according to spec

RE: SPI initialization according to spec

Emil — Wed, 10 Jun 2015 12:54:36 GMT

By the way - The gap is as much as > 40us between the 2 first bytes and the 3rd byte. This can be a problem when reading X Y Z data. I read a post here about having "gapless" burst transfers here: devzone.nordicsemi.com/.../

But is this relevant with the current SDK? I'd like to just use the buffer directly to have optimum burst performance.

RE: SPI initialization according to spec

Emil — Wed, 10 Jun 2015 10:31:17 GMT

It is the ADXL362 itself I think. I searched on various forums etc, and they had to be careful about cable lengths and add filtering caps to ground etc.

A Rigol 1054Z is on the way so I can see how that behaves in comparison :)

RE: SPI initialization according to spec

MartinBL — Wed, 10 Jun 2015 10:20:41 GMT

Happy to help. Is it the ADXL362 itself or a combination of the sensor and the PCB that makes it is sensitive? Just curious. I use a Saleae logic analyzer myself and has never had a problem with it.

RE: SPI initialization according to spec

Emil — Wed, 10 Jun 2015 09:28:32 GMT

Thanks for all your help! I actually had to use all the standard settings, and use MSB configuration. In practice the buffers have to be the same size or rx > tx if I want to get anything from the dummy bytes I suppose. I am glad I finally sorted out SPI with your API.

The ADXL362 is VERY sensitive to noise so I have to do some analog design to give it a nicer and more noise free transmission line.

So a reminder: CPOL = 0 = SPI_CONFIG_CPOL_ActiveHigh

CPHA = 0 = SPI_CONFIG_CPHA_Leading

This = MODE 0

RE: SPI initialization according to spec

MartinBL — Wed, 10 Jun 2015 09:19:55 GMT

Glad it finally works :) No, they don't need to be the same size. If the SPI executes a transfer with a rx_buffer larger than the tx_buffer it will shift out dummy bytes until the rx_buffer is full. If the tx_buffer is larger than the rx_buffer the redundant received bytes will be discarded. E.g. if your tx_buffer is 10 bytes and the rx_buffer is 3 then the first three incoming bytes will be put in the rx_buffer and the last 7 will be discarded.

Regarding one large vs two small buffers I don't know really. Personally I think it would be easier to read and use the code with two arrays. But it is really up to you.

RE: SPI initialization according to spec

Emil — Wed, 10 Jun 2015 08:56:47 GMT

RESPONSE TO RESPONSE TO EDIT 2 :)

I made it work with this dummy byte! I had to remove the Saleae Logic from the circuit since it introduced noise and it didn't work reliably.

So let me get this straight. The RX and TX buffers passed in must be in the same size. Is it sensible to have one big buffer of 10 bytes as opposed to 2 buffers with 5 bytes each?

The command is 2 bytes + dummy byte = 3 bytes.

The response can either be a byte or an uint = 1-2 = 2 at most. = 4 bytes total.

So then I have a buffer with 8 bytes, where the offset 4 is passed to the RX. I then read 4+2 = 6th index to get the response which is 1 or 2 bytes.

static uint8_t _buf[8];

...

_buf[0] = ADXL34X_CMD_READ;
_buf[1] = reg;
_buf[2] = SPI_DEFAULT_TX_BYTE;

if (reg & REG_2B) {
	rxcnt = 2;
	_buf[3] = SPI_DEFAULT_TX_BYTE;
}
else {
	rxcnt = 1;
}
uint32_t status = spi_master_send_recv(SPI_MASTER_HW, &_buf[0], 2 + rxcnt, &_buf[4], 2 + rxcnt);

...

return _buf[6]; // add conversion for 16 bit values

RE: SPI initialization according to spec

MartinBL — Wed, 10 Jun 2015 07:25:13 GMT

Had to edit my answer due to character limitations in the comment section.

RE: SPI initialization according to spec

Emil — Wed, 10 Jun 2015 06:43:33 GMT

It was LSB / MSB confusion in analyzer vs code

RE: SPI initialization according to spec

Milad — Wed, 10 Jun 2015 03:55:57 GMT

Here is a problem I noticed about your SPI communication. Your clock and MOSI has to happen in correlation. But from the picture you post I see your clock leads the MOSI by at least 4 bits meaning it is not understood by the ADXL62 at all

RE: SPI initialization according to spec

Emil — Tue, 09 Jun 2015 14:03:19 GMT

Right, I assumed that the softdevice / SPI master library did this for you as you need a clock to even receive anything. I specify 1 byte rx count, and then I would assume that the SPI library understands that it has to send 8 additional clock pulses to read the response. Is this not the case? I double and triple checked that I pass rxcount = 1.

uint32_t spi_master_send_recv(const spi_master_hw_instance_t spi_master_hw_instance, uint8_t * const p_tx_buf, const uint16_t tx_buf_len, uint8_t * const p_rx_buf, const uint16_t rx_buf_len)

RE: SPI initialization according to spec

MartinBL — Tue, 09 Jun 2015 14:01:06 GMT

Looking at the Register Read timing diagram in the ADXL362 datasheet, Figure 36, pp 20, it actually seems like you are supposed to send an instruction byte, an address byte and then you can expect to get data back. While transferring the two first bytes the MISO line will be in an undefined state (that is how I read the timing diagram anyway). Looking at your image again it looks like you are only sending two bytes and then no more clocks. You should try to send a third "dummy byte", with just ones or zeroes.

RE: SPI initialization according to spec

Emil — Tue, 09 Jun 2015 12:48:11 GMT

Good :)

Yes
Yes - it matches www.analog.com/.../ADXL362.pdf page 20
No
I am as sure as can be. Made sure I have power connection all the way. This is my 2nd eval sensor

which I carefully soldered, and made sure there were no shorts, and I didn't reverse polarity.

I am pretty desperate right now as I have used a good week on this.

But the question: Shouldn't clock be sent when it waits for that byte with an answer? I would expect 8 more clocks. No clocks, no response right?

RE: SPI initialization according to spec

MartinBL — Tue, 09 Jun 2015 12:42:42 GMT

Seems like imgur was blocked on our network, but I found a way ;). It looks like your sensor is either dead/unresponsive or that there is still something wrong with your pin mapping.

Are your read/write command bytes defined correctly?
Did you experiment with least/most significant byte order, polarity and phase settings?
Are you able to test the SPI by e.g. using the master loopback example?
Are you sure that the sensor is powered up and running?

RE: SPI initialization according to spec

Emil — Tue, 09 Jun 2015 12:19:06 GMT

http://i.imgur.com/1eLzbgU.png

RE: SPI initialization according to spec

MartinBL — Tue, 09 Jun 2015 12:17:43 GMT

Something went wrong when you uploaded the image and I am not able to see it.

RE: SPI initialization according to spec

MartinBL — Fri, 05 Jun 2015 13:32:29 GMT

It can certainly be the problem, but that is impossible for me to say for sure. You will just need to experiment and see if it shows any signs of life at all.

RE: SPI initialization according to spec

Emil — Fri, 05 Jun 2015 13:25:48 GMT

Thanks a lot. I get NRF_ERROR_BUSY (17) from spi_master_send_recv, I made sure the connections are correct. When disconnecting everything I get no errors. Today I had some bad luck with the accelerometer (reversed the polarity, VS and GND are right next to eachother!) So that might be a problem. Could a toasted device cause the busy error or can it be something else? Thanks, and have a nice weekend :)

RE: SPI initialization according to spec

MartinBL — Fri, 05 Jun 2015 12:57:55 GMT

No worries. Hope it works out for you.

RE: SPI initialization according to spec

Emil — Fri, 05 Jun 2015 12:35:59 GMT

Thank you so much! This is exactly the document I was looking for (Page 11)!

RE: SPI initialization according to spec

MartinBL — Fri, 05 Jun 2015 12:28:32 GMT

If you have defined SPI_MASTER_0_ENABLE in your makefile, as you say in your first post, you will need to use the upper block, SPIM0_SCK_PIN, etc. But, of course you will need to connect your sensor to the matching pin numbers OR change the defines in your code.

EDIT: Yes AIN2 is mapped to pin 1, you can e.g. see this in the Pin Assignment chapter in the Product Specification document.

RE: SPI initialization according to spec

Emil — Fri, 05 Jun 2015 12:12:26 GMT

You are right. This is my pca10028.h (nRF51_SDK\examples\bsp\pca10028.h). release_notes.txt says "nRF51 SDK v8.1.0".

#define SPIM0_SCK_PIN       4     /**< SPI clock GPIO pin number. */
#define SPIM0_MOSI_PIN      1     /**< SPI Master Out Slave In GPIO pin number. */
#define SPIM0_MISO_PIN      3     /**< SPI Master In Slave Out GPIO pin number. */
#define SPIM0_SS_PIN        2     /**< SPI Slave Select GPIO pin number. */

...

#define SER_APP_SPIM0_SCK_PIN       29     // SPI clock GPIO pin number.
#define SER_APP_SPIM0_MOSI_PIN      25     // SPI Master Out Slave In GPIO pin number
#define SER_APP_SPIM0_MISO_PIN      28     // SPI Master In Slave Out GPIO pin number
#define SER_APP_SPIM0_SS_PIN        12     // SPI Slave Select GPIO pin number
#define SER_APP_SPIM0_RDY_PIN       14     // SPI READY GPIO pin number
#define SER_APP_SPIM0_REQ_PIN       13     // SPI REQUEST GPIO pin number

The SPIM0_SCK_PIN etc was pulled from the master slave example. (nRF51_SDK\examples\peripheral\spi_master_with_spi_slave\main.c(92)) Which one should I actually use? :)

EDIT: And NRF_ADC_CONFIG_INPUT_2 or ADC_CONFIG_PSEL_AnalogInput2 is actually P0.01 on the NRF51-DK board... But how I found out I can't even remember. :) I am already using ADC_CONFIG_PSEL_AnalogInput2 so if I use SPIM0_MOSI_PIN it will conflict? Aren't P0.01-P0.06 ADC inputs?

RE: SPI initialization according to spec

MartinBL — Fri, 05 Jun 2015 12:07:04 GMT

Alright, I found this file. Which defines:

SPI_PSELMOSI0 = p25,
SPI_PSELMISO0 = p28,
SPI_PSELSS0   = p24,
SPI_PSELSCK0  = p29,

But I am still confused since in the code block in your initial post you use the define names SPIM0_SCK_PIN, SPIM0_MISO_PIN, SPIM0_MOSI_PIN and SPIM0_SS_PIN. These names resembles the defines in the pca10028.h file and not the defines in the file in my link.

I don't know whether least significant bit first is standard or not and I couldn't find the info in the datasheet so you will have to trial and error on this one.

I guess CSN stands for Chip Select Negative, meaning that the signal is active low.

RE: SPI initialization according to spec

Emil — Fri, 05 Jun 2015 11:49:51 GMT

RESPONSE TO EDIT

Thanks, I have actually looked in the file before, but trusted the MBED one.

#define SER_CON_SPIS_SCK_PIN        29    // SPI SCK signal.
#define SER_CON_SPIS_MOSI_PIN       25    // SPI MOSI signal.
#define SER_CON_SPIS_MISO_PIN       28    // SPI MISO signal.
#define SER_CON_SPIS_CSN_PIN        12    // SPI CSN signal. <--- CS / SS / SEL???
#define SER_CON_SPIS_RDY_PIN        14    // SPI READY GPIO pin number.
#define SER_CON_SPIS_REQ_PIN        13    // SPI REQUEST GPIO pin number.

So CS is Pin 12 then.

I am doing a soft reset of the chip and wait 100 ms and you should be able to get manufacturer ID etc from it before doing anything.

#define ADXL_REG_DEVID_AD	0x00
#define ADXL_REG_PARTID		0x02

// ...

Adxl362_Write(ADXL_REG_SOFT_RESET, 'R');

// A latency of approximately 0.5 ms is required after soft reset.
nrf_delay_ms(100);

manId = Adxl362_Read(ADXL_REG_DEVID_AD);
partId = Adxl362_Read(ADXL_REG_PARTID);

Read function:

static int Adxl362_Read(unsigned reg)
{
	unsigned char buf[4];
	unsigned rxcnt;
	uint32_t status;

	buf[0] = ADXL34X_CMD_READ;
	buf[1] = reg;

	if (reg & REG_2B) {
		rxcnt = 2;
	}
	else {
		rxcnt = 1;
		buf[3] = 0;
	}

	status = spi_master_send_recv(SPI_MASTER_HW, &buf[0], 2, &buf[2], rxcnt);

	return (status < 0) ? status : (uint16_t)buf[2];
}

Yes everything is connected correctly now I hope since pin 24 is moved to pin 12! I will do some more testing. Thanks a lot.

My current config is:

spi_config.SPI_CONFIG_ORDER = SPI_CONFIG_ORDER_LsbFirst; // : SPI_CONFIG_ORDER_MsbFirst);
spi_config.SPI_CONFIG_CPOL = SPI_CONFIG_CPOL_ActiveLow;
spi_config.SPI_CONFIG_CPHA = SPI_CONFIG_CPHA_Leading;
spi_config.SPI_Freq = SPI_FREQUENCY_FREQUENCY_M1;

It is LsbFirst that is the standard right?

Thanks again!

RE: SPI initialization according to spec

MartinBL — Fri, 05 Jun 2015 11:35:40 GMT

Edited my answer above.

RE: SPI initialization according to spec

Emil — Fri, 05 Jun 2015 10:35:24 GMT

Thank you for your response and sorry for the confusion ! When I say "pin" I mean the pin number on the NRF51-DK pinout on the actual board. Like P0.24, not in the .h file :)

The pinout image is here: developer.mbed.org/.../Nordic-nRF51-DK

"SEL" is LED 4 and P0.24. This is what I connected to "CS" on the ADXL632Z eval kit. I assume this is pin_slave_select. This is a correct mapping for SDK 8 right? I am using SDK 8.

I tried SPI_CONFIG_CPOL_ActiveLow before, but there wasn't any difference. Good to hear that the rest is OK.

Also, 0xFF is returned when I disconnect everything. So it behaves just like it wasn't connected at all. I have ordered another eval kit from them and will see if I get the same results.

A suggestion for the SDK to clear up the CPOL stuff in the comments in the SDK :)