SPIM Receive data is always 1bit shift Thingy91

RE: SPIM Receive data is always 1bit shift Thingy91

Håkon Alseth — Thu, 08 May 2025 11:23:03 GMT

Hi,

Glad to hear that you got it working!

Kind regards,

Håkon

RE: SPIM Receive data is always 1bit shift Thingy91

PedroR — Thu, 08 May 2025 09:18:14 GMT

Hi,

I think it was a hardware problem, maybe because of connect the logic analyzer (3v3) to the Thingy's SPI pins (1v8)... I have changed the psram and it works as expected.

RE: SPIM Receive data is always 1bit shift Thingy91

PedroR — Wed, 07 May 2025 14:03:34 GMT

Hi,

I'm investigating this today and making these changes. However, I actually set since the beginning the ADXL chip selects to 1 during test initialization. With your changes, SPI behavior doesn't change. Could you please review the ZIP file? Maybe I'm missing something.

devzone.nordicsemi.com/.../2654.psram.zip

RE: SPIM Receive data is always 1bit shift Thingy91

Håkon Alseth — Wed, 07 May 2025 13:38:45 GMT

Hi,

I think I found the issue.

If you look at the compiled zephyr.dts file in build/psram/zephyr/zephyr.dts folder, you can see that the spi3 node looks like this:

			spi3: spi@b000 {
				compatible = "nordic,nrf-spim";
				#address-cells = < 0x1 >;
				#size-cells = < 0x0 >;
				reg = < 0xb000 0x1000 >;
				interrupts = < 0xb 0x1 >;
				max-frequency = < 0x7a1200 >;
				easydma-maxcnt-bits = < 0xd >;
				status = "okay";
				cs-gpios = < &gpio0 0xa 0x1 >;
				pinctrl-0 = < &spi3_default >;
				pinctrl-1 = < &spi3_sleep >;
				pinctrl-names = "default", "sleep";
				adxl362: adxl362@0 {
					compatible = "adi,adxl362";
					spi-max-frequency = < 0x7a1200 >;
					reg = < 0x0 >;
					int1-gpios = < &gpio0 0x9 0x0 >;
				};
				adxl372: adxl372@1 {
					compatible = "adi,adxl372";
					spi-max-frequency = < 0x7a1200 >;
					reg = < 0x1 >;
					int1-gpios = < &gpio0 0x6 0x0 >;
				};
				reg_my_spi_master: spi-dev-a@0 {
					reg = < 0x0 >;
				};
			};

It looks like the adxl and reg_my_spi_master points to index 0 of the "cs-gpios" structure, which will cause some adxl-specific commands to be sent to your PSRAM IC.

In your overlay, declare the other cs-gpios, to ensure that they are inactive and change the reg to point to '2', as done here:

&spi3 {
    compatible = "nordic,nrf-spim";
    status = "okay";
    cs-gpios = <&gpio0 8 GPIO_ACTIVE_LOW>, <&gpio0 7 GPIO_ACTIVE_LOW>, <&gpio0 10 GPIO_ACTIVE_LOW>;
    pinctrl-0 = <&spi3_default>;
    pinctrl-1 = <&spi3_sleep>;
    pinctrl-names = "default", "sleep";
    reg_my_spi_master: spi-dev-a@2 {
		reg = <2>;
	};
};

If the other CS pins are floating, the other sensors can start shifting data out on the MISO line, causing corruption/collision on the bus.

Kind regards,

Håkon

RE: SPIM Receive data is always 1bit shift Thingy91

PedroR — Wed, 07 May 2025 06:57:18 GMT

Yes, I am using TP7, and I had cut SB14.

RE: SPIM Receive data is always 1bit shift Thingy91

Håkon Alseth — Tue, 06 May 2025 15:36:50 GMT

Hi,

[quote user="PedroR"]Here, it stops between each byte, and in the NRF not. What do you think? [/quote]

That should not have an impact, unless the IC has very unusual timing requirements.

Could you confirm the pins that you use? Is it P0.10 for CSN?

If yes, then this is by default connected to the RESET pin of the nRF52 device on thingy91:

Meaning that SB14 needs to be cut in order to use this as a normal GPIO.

Kind regards,

Håkon

RE: SPIM Receive data is always 1bit shift Thingy91

PedroR — Tue, 06 May 2025 14:53:33 GMT

Hi,

I tried it with a different microcontroller (RP2040) with a 3v3 PSRAM instead of 1.8v, and it works with the same SPI mode and 500KHz. The only difference that I can imagine is related with the clock signal. Here, it stops between each byte, and in the NRF not. What do you think? How can I fix it in the Thingy91?

RE: SPIM Receive data is always 1bit shift Thingy91

Håkon Alseth — Tue, 29 Apr 2025 13:57:06 GMT

Hi,

[quote user="PedroR"]0xee 0b11101110 -> (0xdb 0b11011011) (0x6d 0b01101101) (0xb6 0b10110110) Same patron again in different order.[/quote]

I am sorry, but I do not see the same pattern as you here as compared to your original written pattern.

Writing all '0xee', then reading 0xdb, and 0x6d, and then 0xb6.

This does not reflect the original written data. Since you do not have control over what is actually written to the device, you can not trust the read out either.

Start with reading a known register and see how that behaves.

Kind regards,

Håkon

RE: SPIM Receive data is always 1bit shift Thingy91

PedroR — Tue, 29 Apr 2025 13:11:09 GMT

Hi,

Take a look when I write these bytes, and the generated patrons:

0x33 0b00110011 -> (0x24 0b00100100) (0x92 0b10010010) (0x49 0b01001001) Bit shifting to the right.

0x66 0b01100110 -> (0x49 0b01001001) (0x24 0b00100100) (0x92 0b10010010) Bit shifting to the right, and repeated data in different order.

0x77 0b01110111 -> (0x6d 0b01101101) (0xb6 0b10110110) (0xdb 0b11011011) Different patron with three 1 in the written value.

0x99 0b10011001 -> (0x24 0b00100100) (0x92 0b10010010) (0x49 0b01001001) Again, same values as 0x33 or 0x66 with different order.

0xbb 0b10111011 -> (0x6d 0b01101101) (0xb6 0b10110110) (0xdb 0b11011011) Same patron as 0x77 with three continuous 1.

0xcc 0b11001100 -> (0x92 0b10010010) (0x49 0b01001001) (0x24 0b00100100) Same patron as two continuous 1 with different order.

0xdd 0b11011101 -> (0xb6 0b10110110) (0xdb 0b11011011) (0x6d 0b01101101) Same as 0xbb or 0x77 with different order.

0xee 0b11101110 -> (0xdb 0b11011011) (0x6d 0b01101101) (0xb6 0b10110110) Same patron again in different order.

0xff 0b11111111 -> 0xff well stored.

I think there are a clear patron depending on the continuous number of bits set to 1 in the written number and their evolution. Which can be confusing is the last 4 bytes, which seems random, but this is because of the number of bytes that I am writing. If I write 32 and read 16, for example, instead of 16-16, the patron will continue.

RE: SPIM Receive data is always 1bit shift Thingy91

Håkon Alseth — Tue, 29 Apr 2025 12:07:16 GMT

Hi,

[quote user="PedroR"]You can see these patterns when I write a byte with two continuous bits settled to 1.[/quote]

Sorry, but I do not see a clear pattern here. Example: Writing all '0xbb' does not give you a consistent read back content.

Please point directly to the example where this happens, and also share the saleae trace file of this.

As previously mentioned, you are not able to read out the static IDs correctly, so something is quite off here. I would strongly recommend on focusing to read out these 64 bits correctly before trying to r/w any data.

Kind regards,

Håkon

RE: SPIM Receive data is always 1bit shift Thingy91

PedroR — Tue, 29 Apr 2025 06:03:51 GMT

Hi,

You can see these patterns when I write a byte with two continuous bits settled to 1.

The answer, despite the values are wrong, it is creating these patrons. The bytes in the logic analyzer seems equal between them (0x24, 0x92, 0x49... truly, seems such a PWM signal, but wrongly parsed with the clock or misaligned, I do not know).

The case is the PSRAM is answering the commands, and storing in the memory some values (if not, these patrons cannot be possible...). So I guess some things are working properly.

The wires are well-connected, and the timing restrictions should not be a problem, reviewing the datasheet and the logic analyzer samples.

RE: SPIM Receive data is always 1bit shift Thingy91

Håkon Alseth — Mon, 28 Apr 2025 13:29:10 GMT

Hi,

[quote user=""]D: Writing 16 bytes to address 0x000c00
D: SPI TX[0]:   2       0x02    0b00000010
D: SPI TX[1]:   0       0x00    0b00000000
D: SPI TX[2]:   12      0x0c    0b00001100
D: SPI TX[3]:   0       0x00    0b00000000
D: SPI TX[4]:   51      0x33    0b00110011
D: SPI TX[5]:   51      0x33    0b00110011
D: SPI TX[6]:   51      0x33    0b00110011
D: SPI TX[7]:   51      0x33    0b00110011
D: SPI TX[8]:   51      0x33    0b00110011
D: SPI TX[9]:   51      0x33    0b00110011
D: SPI TX[10]: 51      0x33    0b00110011
D: SPI TX[11]: 51      0x33    0b00110011
D: SPI TX[12]: 51      0x33    0b00110011
D: SPI TX[13]: 51      0x33    0b00110011
D: SPI TX[14]: 51      0x33    0b00110011
D: SPI TX[15]: 51      0x33    0b00110011
D: SPI TX[16]: 51      0x33    0b00110011
D: SPI TX[17]: 51      0x33    0b00110011
D: SPI TX[18]: 51      0x33    0b00110011
D: SPI TX[19]: 51      0x33    0b00110011
D: memc_is66wvs4m8_write: 0
D: Reading 16 bytes from address 0x00000c00
D: SPI RX[0]:   0       0x00    0b00000000
D: SPI RX[1]:   0       0x00    0b00000000
D: SPI RX[2]:   0       0x00    0b00000000
D: SPI RX[3]:   0       0x00    0b00000000
D: SPI RX[4]:   36      0x24    0b00100100
D: SPI RX[5]:   146     0x92    0b10010010
D: SPI RX[6]:   73      0x49    0b01001001
D: SPI RX[7]:   36      0x24    0b00100100
D: SPI RX[8]:   146     0x92    0b10010010
D: SPI RX[9]:   73      0x49    0b01001001
D: SPI RX[10]: 36      0x24    0b00100100
D: SPI RX[11]: 146     0x92    0b10010010
D: SPI RX[12]: 73      0x49    0b01001001
D: SPI RX[13]: 36      0x24    0b00100100
D: SPI RX[14]: 146     0x92    0b10010010
D: SPI RX[15]: 73      0x49    0b01001001
D: SPI RX[16]: 130     0x82    0b10000010
D: SPI RX[17]: 62      0x3e    0b00111110
D: SPI RX[18]: 3       0x03    0b00000011
D: SPI RX[19]: 253     0xfd    0b11111101[/quote]

I am unable to see a pattern here that matches your description:

[quote user=""]The problem I'm facing is that the data I read is shifted. I[/quote]

0x33 shifted, either way, is not equal to the data that you read back. There are bit flips in addition, making this a more random pattern than a direct shift.

This is similar in all your other write/reads.

[quote user=""]D: Manufacturer ID: 0x31
D: KGD: 0x85
D: Device Density: 8 Mb
E: Error: Manufacturer ID does not match expected value of 0x9d
E: Error: Could not read vendor id
D: memc_is66wvs4m8_init: -5[/quote]

This also seems to be a mismatch. Are you certain that you have connected MISO/MOSI correctly between your devices?

Have you checked if there are any power-up restrictions/timing or similar on this device?

Kind regards,

Håkon