Teensy 4.1 DMA based UART for Serial6, for both tx and rx

is there any example code or available library to facilitate using Serial6 with DMA, as std Serial6 is interfering with one of my interrupt routines?
 
Try as I might, I have not found anything that works for me. I tried dmaserialteensy40 lib, but it seems to have buffer issues
 
If Serial6 interrupts are interfering with another interrupt, have you tried setting that interrupt to a higher priority? Or can you tell us why Serial6 is a problem?
 
Indeed I have increased the priority to 0. It's essential for me to utilise dma for serial6. My other int is doing a lot of work at 20us cycle time.
 
I have tried serial3 as well...same problem...it's not a specific serial port that is the problem, but rather the mere utilisation interrupt driven uart operation
 
Thanks. I've added both of these to the list at the end of the hardware serial page.

If anyone knows of more alternate or specialized serial library code, please tell me and I'll add them to this list. Hopefully long-term having a complete list on the hardware serial page will help everyone.
 
Though I do wonder why Sicco defined Serial6 differently (i.e. with null pointers) to all other Serial#. Is this an oversight???

DMA_Serial6:
static DMA_UART::hardware_t UART1_Hardware = {
6, 1, IRQ_LPUART1,
&DMA_Serial6_isr_uart,
&DMA_Serial6_isr_dma,
CCM_CCGR5, CCM_CCGR5_LPUART1(CCM_CCGR_ON),
{{25,2, nullptr, 0}, {0xff, 0xff, nullptr, 0}},
{{24,2, nullptr, 0}, {0xff, 0xff, nullptr, 0}},
IRQ_UART_PRIORITY,
IRQ_DMA_PRIORITY,
XBARA1_OUT_LPUART1_TRG_INPUT
};

cf eg DMA_Serial5:
static DMA_UART::hardware_t UART8_Hardware = {
5, 8, IRQ_LPUART8,
&DMA_Serial5_isr_uart,
&DMA_Serial5_isr_dma,
CCM_CCGR6,
CCM_CCGR6_LPUART8(CCM_CCGR_ON),
{{21,2, &IOMUXC_LPUART8_RX_SELECT_INPUT, 1}, {46, 2, &IOMUXC_LPUART8_RX_SELECT_INPUT, 0}},
{{20,2, &IOMUXC_LPUART8_TX_SELECT_INPUT, 1}, {47, 2, &IOMUXC_LPUART8_TX_SELECT_INPUT, 0}},
IRQ_UART_PRIORITY,
IRQ_DMA_PRIORITY,
XBARA1_OUT_LPUART8_TRG_INPUT
};

&
DMA_Serial4:
static DMA_UART::hardware_t UART3_Hardware = {
4, 3, IRQ_LPUART3,
&DMA_Serial4_isr_uart,
&DMA_Serial4_isr_dma,
CCM_CCGR0, CCM_CCGR0_LPUART3(CCM_CCGR_ON),
{{16,2, &IOMUXC_LPUART3_RX_SELECT_INPUT, 0}, {0xff, 0xff, nullptr, 0}},
{{17,2, &IOMUXC_LPUART3_TX_SELECT_INPUT, 0}, {0xff, 0xff, nullptr, 0}},
IRQ_UART_PRIORITY,
IRQ_DMA_PRIORITY,
XBARA1_OUT_LPUART3_TRG_INPUT
};
 
Though I do wonder why Sicco defined Serial6 differently (i.e. with null pointers) to all other Serial#.

Most of the LPUART peripherals inside the chip can have their RX & TX signals routed to different pins. Even if those pins are among the many that aren't routed on the PCB, properly configuring the hardware involves setting up the input select register. To support the ability to actually 2 different pins, 2 sets of config for the mux and input select registers are needed. But for a case like Serial6 which can't route to any other pins, less is needed. That's why these look different. It's not an oversight. It's actually a very well thought out description of the hardware capability, which isn't identical for all the ports.

KurtE deserves most of the credit for this hardware description scheme, which is in the core library HardwareSerial class.
 
I'm still having the original issue. Whether I use Serial6 or DMA_Serial6, with my high priority interrupt running at priority 16 (ive tried 0 as well), and when using Socco's DMA_Serial code set at priority 32
#define IRQ_UART_PRIORITY 32 //192 //32 //32 // 0 = highest priority, 255 = lowest
#define IRQ_DMA_PRIORITY 32 //192 //32 //32 // 0 = highest priority, 255 = lowest
I still get disturbances in my high priority interrupt when Serial6 receives data, even if that high priority interrupt code doesn't touch any variables associated. This doesn't happen if i direct the comms through Serial (ie USB).
 
Its as though the digital output update rate gets stalled, thereby leaving my code-controlled digital output pulse width on too long (which is how i observe the disturbance on a scope). The ISR doesn't seem to be disturbed in duration or period (or elapsedMicros becomes inaccurate?), but my code-controlled digital output pulse width does.
 
Why set the DMA priority that high? Probably little else going on that 64 or 128 wouldn't act the same as far as Rx speed and messing with the code controlling the digital IO. Interesting that USB DMA code doesn't cause issues.

Not seeing 'code-controlled digital output pulse' code? Is it using constant pin #'s and digitalWriteFast()? And that is the high priority interrupt?
 
i have tried DMA priority at various settings...32....192......255...16.....same result.

digital output is using digitalWriteFast, on a fixed pin, controlled by the high priority interrupt.
 
defragster....you mentioned its interesting that the USB DMA code isnt messing with it; im not using DMA explicitly with the USB Serial usage. Just std USB Serial does not cause the disturbance.
 
Is it just with Serial6, or also Serial1, Serial2, Serial3, Serial4, Serial5, Serial7 or Serial8?

Its as though the digital output update rate gets stalled, thereby leaving my code-controlled digital output pulse width on too long (which is how i observe the disturbance on a scope). The ISR doesn't seem to be disturbed in duration or period (or elapsedMicros becomes inaccurate?), but my code-controlled digital output pulse width does.
Making a PWM signal in software is maybe not the best way. Hardware timers would be better. The imxrt1062 has plenty of those.
 
i have also tried SMA_Serial3, which did the same thing.

Code to define the high priority interrupt is:
samplingTimer.begin(samplingISR, INT_TIME); // Start the sampling timer
samplingTimer.priority(16); // highest priority=0 (0-255)

This fires every 25us, and controls the pulse width with 25us granularity. The same ISR performs copious FP math, based on data collected via SPI / 16 bit ADC.

ADC setup code:
adc.reset();
adc.setRange(0);
adc.setOversampling(0);
NVIC_SET_PRIORITY(IRQ_LPSPI4, 18); // Set SPI interrupt to higher priority
NVIC_ENABLE_IRQ(IRQ_LPSPI4);
...setting the SPI priority to 18, just below my high prio task(prio 0), and above the DMA Serial (prio32).
 
Back
Top