New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix SPI when used with PSRAM #3339
Comments
What happens with SPI? It's possible the external RAM prevents DMA. (I have a JTAG library started here: https://github.com/adafruit/Adafruit_CircuitPython_JTAG based on tinyfpga's programmer for the Mach XO2) |
I'd say SPI doesn't work at all now :) but I don't know the details, This project esp32ecp5 is in use whole year for micropython ESP32-WROOM for |
Ok, we'll need to retest SPI. Please let me know if you have a simple test case that fails. |
SPI SD card won't mount. |
Another even simpler test: SPI LOOPBACK, connect MISO-MOSI IO35-IO37 adafruit-circuitpython-espressif_saola_1_wrover-en_US-20200827-fe73cfb.bin passed this test adafruit-circuitpython-espressif_saola_1_wrover-en_US-20200829-d858d04.bin https://github.com/emard/esp32ecp5/blob/master/circuitpython/spiloopback.py#L1 fails as functions spi.readinto(rx) or spi.write_readinto(tx,rx) |
@emard Can you confirm it works for you with psram disabled? I think we're trying to dma from memory that can't be used for DMA. |
where is download for non-PSRAM circuitpython? I have only WROVER-S2 with PSRAM and |
@emard try loading the WROOM version. It should work just fine and not use the PSRAM. |
spi loopback works with adafruit-circuitpython-espressif_saola_1_wroom-en_US-20200831-877a4f4.bin the same example that works for non-PSRAM version, but I can't test real thing ecp5.py because |
Ok, thanks for testing this! I've gotta decide how to fix it. We want bytearrays in PSRAM by default but need them in RAM when sending them to SPI. |
I need min buf size of 4K. If I can have 16K there's small performance gain
python maybe needs help to place bytearray in RAM instead of PSRAM.
buf=machine.ram(bytearray(512)) or similar... but that are just my random
thoughts, any fix is good thing :)
…On 9/1/20, Scott Shawcroft ***@***.***> wrote:
Ok, thanks for testing this! I've gotta decide how to fix it. We want
bytearrays in PSRAM by default but need them in RAM when sending them to
SPI.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#3339 (comment)
|
Do you reuse the buffer? Would it work if we moved the bytearray into RAM when first used for DMA? |
It's all 600 lines of my code so I can fit this to let it work
buffer is reused for performance (it is allocated only once)
but just give me some hint how should I use it now.
I can make during init a dummy DMA for the first time to
let buffer move into RAM or something similar, just fine
…On 9/2/20, Scott Shawcroft ***@***.***> wrote:
Do you reuse the buffer? Would it work if we moved the bytearray into RAM
when first used for DMA?
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#3339 (comment)
|
Reusing it is definitely the way to go. I don't think there is a way to currently get this to work. It requires some changes under the hood to move memory as needed. Hopefully it'll just work in the future with a copy cost on first DMA. |
Ok, let me know when I can pull compiled binary and test.
In the meantime I took WROVER-E with micropython and
tried my source with 256KB buffer which is required to hold
content of erase block of new FLASH chips and it works good,
and with some speedup as buffer is larger.
I don't know how they make this work, is old ESP32
better handling PSRAM DMA but I guess WROVER-E
with all loaded is not likely to have 256KB free in RAM.
…On 9/3/20, Scott Shawcroft ***@***.***> wrote:
Reusing it is definitely the way to go.
I don't think there is a way to currently get this to work. It requires some
changes under the hood to move memory as needed. Hopefully it'll just work
in the future with a copy cost on first DMA.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#3339 (comment)
|
I tried current binary but it still doesn't work, I have tried this: adafruit-circuitpython-espressif_saola_1_wrover-en_US-20200906-a9779b9.bin |
My plan is to work on it tomorrow. I'll update here when a fix is created. |
Ok, I've confirmed its very fast at transmitting zeroes. :-) Working on a fix now. |
This fixes SPI with PSRAM allocated buffers. DMA with SPI2 was attempted but produced junk output. This manual copy is less than 2x slower than DMA when not interrupted. Fixes #3339
I have ported a small project for ECP5 JTAG programmer
from micropython to circuitpython:
https://github.com/emard/esp32ecp5/tree/master/circuitpython
Last known good circuitpython that runs it correctly was this:
adafruit-circuitpython-espressif_saola_1_wrover-en_US-20200827-fe73cfb.bin
In later versions 2MB PSRAM support appears which is absolutely great,
but now SPI is either not working or has issues if initialized and deinitialized often.
This project needs to switch between bitbanging of JTAG pins and
driving the same pins by hardware SPI for speed. JTAG traffic
doesn't always consist of multiple of 8 clocks so SPI can't be constantly
used.
During the switch from bitbanging to SPI and back,
glitches appear (pins change state while
we didn't want them to).
Some glitches are tolerable and some must be workarounded so
the project is sensitive to what is done with the pins.
The text was updated successfully, but these errors were encountered: