Skip to content
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

STM SPI DMA utils, malloc in ISR #427

Open
chrissnow opened this issue Jan 22, 2025 · 3 comments
Open

STM SPI DMA utils, malloc in ISR #427

chrissnow opened this issue Jan 22, 2025 · 3 comments

Comments

@chrissnow
Copy link

DMA_HandleTypeDef * dmaHandle = malloc(sizeof(DMA_HandleTypeDef));

When using SPI with DMA and "transfer" in an ISR the first time it's called malloc will be called and fail as it's not allowed.

You can workaround it by ensuring you have used transfer before even if it's a dummy transaction.
Perhaps we should link during enabling DMA or SPI object creation?

@multiplemonomials
Copy link
Collaborator

multiplemonomials commented Feb 11, 2025

Hmm yeah that is an issue, but I'm not sure if there's an easy way around it other than doing what you said. TBH I'm not sure if we want to actually support doing DMA SPI from an ISR, but I can imagine there are some uses for it so IDK if we want to disallow it entirely.

@chrissnow
Copy link
Author

DMA in an ISR is incredibly useful when dealing with fast continual conversion ADC's etc.
Should we just link it when enabling DMA? it's unlikely you would want to do that in an ISR, at least we would not lose functionality.

@multiplemonomials
Copy link
Collaborator

Maybe the way to go is to add a configuration option like target.spi-always-allocate-dma (or something). If set, it would allocate DMA channels when a SPI is initially constructed, so that it is guaranteed to work from an ISR, at the cost of more RAM usage when constructing each SPI.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants