2017-09-27 01:55 PM
I have serial data coming in at a high rate, so DMA is the only reasonable way to handle this firehose of data. I believe I have _nearly_ everything set up properly, but for the interrupt that signals DMA completion and the need to reset pointers and restart DMA.
I know (or perhaps just think) I should ultimately get to DMA2_Channel7_IRQHandler() for the selections I've made, but the interrupt never occurs. So I don't think I've properly asked it to be triggered, and wonder just where I should do that.All of the underpinnings were generated by STM32CubeMX version 4.22.0. Is this where my troubles begin? There seems to be a lot of anti-CubeMX sentiment in the ranks.
Until I get this interrupt properly set up, the 0x800 bytes of buffer fill up, and the pointers don't change.
Please?
2017-09-28 06:23 AM
Digging deeper, I find that the interrupt in question is set up in this routine:
static void MX_DMA_Init(void)
{ /* DMA controller clock enable */ __HAL_RCC_DMA1_CLK_ENABLE(); __HAL_RCC_DMA2_CLK_ENABLE();/* DMA interrupt init */
/* DMA1_Channel4_IRQn interrupt configuration */ HAL_NVIC_SetPriority(DMA1_Channel4_IRQn, 0, 0); HAL_NVIC_EnableIRQ(DMA1_Channel4_IRQn); /* DMA2_Channel7_IRQn interrupt configuration */ HAL_NVIC_SetPriority(DMA2_Channel7_IRQn, 0, 0); HAL_NVIC_EnableIRQ(DMA2_Channel7_IRQn);}
so one might think that this should work. But the interrupt doesn't fire. I supposed it could be a hardware failure, but I need to exhaust all of my culpability before I jump down that rabbit hole.
Any ideas?2017-09-28 09:09 AM
So, I jumped down that rabbit hole with a quick prototype, and with the new hardware, that interrupt fires OK. This is going to anger the hardware engineer Oh, well, some things just can't be helped.
Thanks,John