Commit e1b4e9b
committed
UART: Always allocate UART objects in the long-lived pool
Particularly when they have buffers that are written via IRQ or DMA,
UART objects do not relocate gracefully. If such an object is
relocated to the long-lived pool after its original creation, the
IRQ or DMA will write to an unexpected location within the Python
heap, leading to a variety of symptoms. The most frequent symptom
is inability to read from the UART.
Consider the particular case of atmel-samd: usart_uart_obj_t
contains a usart_async_descriptor contains a _usart_async_device.
In _sercom_init_irq_param the address of this contained
_usart_async_device is assigned to a global array
sercom_to_sercom_dev which is later used from the interrupt context
_sercom_usart_interrupt_handler to store the received data in the
right ring buffer.
When the UART object is relocated to the long-lived heap, there's no
mechanism to re-point these internal pointers, so instead take the
cowardly way and allocate the UART object as long-lived.
Happily, almost all UART objects are likely to be long-lived, so
this is unlikely to have a negative effect on memory usage or heap
fragmentation.
Closes: adafruit#10561 parent 2e80f37 commit e1b4e9b
File tree
1 file changed
+5
-1
lines changed1 file changed
+5
-1
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
66 | 66 | | |
67 | 67 | | |
68 | 68 | | |
69 | | - | |
| 69 | + | |
| 70 | + | |
| 71 | + | |
| 72 | + | |
| 73 | + | |
70 | 74 | | |
71 | 75 | | |
72 | 76 | | |
| |||
0 commit comments