search

esp-rs / esp-hal

no_std Hardware Abstraction Layers for ESP32 microcontrollers
https://docs.esp-rs.org/esp-hal/
Apache License 2.0
757 stars 212 forks source link

Bugs in FlashSafeDma<SpiDma> #1798

Closed Dominaezzz closed 2 months ago

Dominaezzz commented 4 months ago

Discovered these while refactoring the DMA APIs. (I'm going to be removing them anyway for the new DMA Move API but I thought it'd be worth mentioning in case someone else runs into it)

Here the result of the transfer isn't copied back into user provided buffer. https://github.com/esp-rs/esp-hal/blob/7ea471c1ac2b7fbb4468a3f4211225e5dec2fe5c/esp-hal/src/spi/master.rs#L1687-L1700 https://github.com/esp-rs/esp-hal/blob/7ea471c1ac2b7fbb4468a3f4211225e5dec2fe5c/esp-hal/src/spi/master.rs#L1801-L1811

Here the DMA buffer isn't being used. https://github.com/esp-rs/esp-hal/blob/7ea471c1ac2b7fbb4468a3f4211225e5dec2fe5c/esp-hal/src/spi/master.rs#L1482-L1491 https://github.com/esp-rs/esp-hal/blob/7ea471c1ac2b7fbb4468a3f4211225e5dec2fe5c/esp-hal/src/spi/master.rs#L1662-L1664 https://github.com/esp-rs/esp-hal/blob/7ea471c1ac2b7fbb4468a3f4211225e5dec2fe5c/esp-hal/src/spi/master.rs#L1683-L1685

plaes commented 3 months ago

Two issues I noticed with current main (5d6354ccbd62527452968074c4a92a4fc6c6a635) as of 2024.07.24 when communicating using async from embassy task on esp32 (revision v3.0).

Firstly, FlashSafeDma transfer hangs with certain buffer sizes: 3, 5, 6 and 8 words (tested up to 12 for now)

Hanging:
[INFO] - WRITE async FlashSafeDma: 0x3ffb0d5f, len: 3
[INFO] - WRITE async SpiDma: 0x3ffb0d5f, len: 3

[INFO] - WRITE async FlashSafeDma: 0x3ffb0d5f, len: 5
[INFO] - WRITE async SpiDma: 0x3ffb0d5f, len: 5

[INFO] - WRITE async FlashSafeDma: 0x3ffb0d5e, len: 6
[INFO] - WRITE async SpiDma: 0x3ffb0d5e, len: 6

[INFO] - WRITE async FlashSafeDma: 0x3ffb0d58, len: 8
[INFO] - WRITE async SpiDma: 0x3ffb0d58, len: 8

Working:
[INFO] - WRITE async FlashSafeDma: 0x3ffb0eb4, len: 2
[INFO] - WRITE async SpiDma: 0x3ffb0eb4, len: 2

[INFO] - WRITE async FlashSafeDma: 0x3ffb0d58, len: 4
[INFO] - WRITE async SpiDma: 0x3ffb0d58, len: 4

[INFO] - WRITE async FlashSafeDma: 0x3ffb0d5f, len: 7
[INFO] - WRITE async SpiDma: 0x3ffb0d5f, len: 7

[INFO] - WRITE async FlashSafeDma: 0x3ffb0d5f, len: 9
[INFO] - WRITE async SpiDma: 0x3ffb0d5f, len: 9

[INFO] - WRITE async FlashSafeDma: 0x3ffb0d5e, len: 10
[INFO] - WRITE async SpiDma: 0x3ffb0d5e, len: 10

[INFO] - WRITE async FlashSafeDma: 0x3ffb0d5f, len: 11
[INFO] - WRITE async SpiDma: 0x3ffb0d5f, len: 11

[INFO] - WRITE async FlashSafeDma: 0x3ffb0d58, len: 12
[INFO] - WRITE async SpiDma: 0x3ffb0d58, len: 12

Secondly received buffer seems to contain only the first byte of the payload (the way I'm currently testing this is sending message from one board to another using LoRa P2P), but I don't know which side is responsible yet.

Dominaezzz commented 3 months ago

Got any code to reproduce that?

plaes commented 3 months ago

Got any code to reproduce that?

Well, repository of my LoRa code is currently here - https://github.com/plaes/rust-lilygo-ttgo-lora32 which uses lora-phy for communication with sx1276 which internally uses embedded-hal-1.0's transfer method: https://github.com/lora-rs/lora-rs/blob/36885275fbfed98578e1a3a48555d973638b6105/lora-phy/src/interface.rs#L40-L42