ESP32-S2: SPI DMA test_asymmetric_dma_transfer fails

[SergioGasquez]

          For some reason, [S2 HIL](https://github.com/esp-rs/esp-hal/actions/runs/10717649673/job/29718015468) is failing this test, I can also reproduce it locally.  Not sure why it only happens in S2 and when using different buffer sizes (using `dma_buffers!(4,4)` passes the test)

main doesnt have any issue with this test in S2

Originally posted by @SergioGasquez in #2074 (comment)

See #2074 (comment) for more information

[Dominaezzz]

Ah yeah it is almost definitely this.

For the S2 the fix is trivial. You just need to change

esp-hal/esp-hal/src/spi/master.rs

Lines 3459 to 3479 in 492e35a

	fn configure_datalen(&self, len: u32) {
	let reg_block = self.register_block();
	let len = if len > 0 { len - 1 } else { 0 };
	#[cfg(any(esp32c2, esp32c3, esp32c6, esp32h2, esp32s3))]
	reg_block
	.ms_dlen()
	.write(|w| unsafe { w.ms_data_bitlen().bits(len) });
	#[cfg(not(any(esp32c2, esp32c3, esp32c6, esp32h2, esp32s3)))]
	{
	reg_block
	.mosi_dlen()
	.write(|w| unsafe { w.usr_mosi_dbitlen().bits(len) });
	reg_block
	.miso_dlen()
	.write(|w| unsafe { w.usr_miso_dbitlen().bits(len) });
	}
	}
	}

to pass the correct lengths for the read and write side rather than the max of both.

[Dominaezzz]

It's also worth noting that this bug would've been swept under the rug (like it is for some of the other chips) if the pdma was being reset during construction like the Gdma currently is.

[bugadani]

Dominic, are you sure this isn't a timing issue? The test passes if I enable defmt which is ironic because without defmt I can't see the backtrace when the test panics :D

[Dominaezzz]

It may very well be, unfortunately probe-rs doesn't seem happy with my S2 so I can't really dig in further.

And given the number of changes that have happened since I made that hypothesis, I won't be surprised if I'm wrong haha

[bugadani]

Thanks for your input, I'm looking into this :)