Hello, I am having a issue with HAL_UARTEx_ReceiveToIdle_DMA on a NUCLEO-H7A3ZI-Q, when using the following code:
uint8_t rx_buffer [4096];
HAL_UARTEx_ReceiveToIdle_DMA(&huart3, rx_buffer, sizeof(rx_buffer));
void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t size){
/*code*/
}My rx_buffer is only populating the first 512 bytes, with the remaining data remaining as 0.
__HAL_DMA_GET_COUNTER(huart3.hdmarx);Provides the incorrect amount of data being passed over serial.
I have used serial plotter and CoolTerm to try and send packets but both hit this 512 byte limit.
rx_buffer not populated past 512 bytes
length correctly calculated as 640 bytes long
1 ACCEPTED SOLUTION
Accepted Solutions
Thank you,
In the attached instance I was expecting 640 bytes + 5 confirmation bytes. However I want to send payloads up to 4096 bytes.
I have mapped the MPU to match the memory areas from the linker script
MEMORY
{
ITCMRAM (xrw) : ORIGIN = 0x00000000, LENGTH = 64K
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 2048K
DTCMRAM1 (xrw) : ORIGIN = 0x20000000, LENGTH = 64K
DTCMRAM2 (xrw) : ORIGIN = 0x20010000, LENGTH = 64K
RAM (xrw) : ORIGIN = 0x24000000, LENGTH = 1024K
RAM_CD (xrw) : ORIGIN = 0x30000000, LENGTH = 128K
RAM_SRD (xrw) : ORIGIN = 0x38000000, LENGTH = 32K
}
Should I disable the MPU during hard faults? Is there anything else standing out.
This is how each region is configured.
| Region memory | Instruction access | Shareable | Cacheable | Bufferable |
| ITCM RAM (0x0000 0000, 64 KB) | Enabled | Not shareable | Not cacheable | Not bufferable |
| FLASH (0x0800 0000, 2 MB) | Enabled | Not shareable | Cacheable | Not bufferable |
| DTCM RAM 1 (0x2000 0000, 64 KB) | Disabled | Not shareable | Not cacheable | Not bufferable |
| DTCM RAM 2 (0x2001 0000, 64 KB) | Disabled | Not shareable | Not cacheable | Not bufferable |
| AXI SRAM (0x2400 0000, 1 MB) | Disabled | Not shareable | Cacheable | Bufferable |
| SRAM_CD (0x3000 0000, 128 KB) | Disabled | Not shareable | Cacheable | Bufferable |
| SRAM_SRD (0x3800 0000, 32 KB) | Disabled | Shareable | Not cacheable | Not bufferable |
I added the following script to replace all of the rx_buffer values with 7:
for (uint16_t i = 0; i < 4096; ++i) {
rx_buffer[i] = 7;
}
Whilst rx_buffer is initially fully populated with 7's, by using breakpoints I can see that it is not updating to match the information sent over serial when the following interrupt is triggered.
void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t size){it would appear my LUT, that has static memory allocation, is being populated by the first correct 512 bytes from somewhere else. (the first 5 bytes are the arbitration field which is why they are skipped in the for loop).
for (uint16_t k = 0, i = 5; i < length + 5; ++k, i += 2) {
lut[k] = (rx_buffer[i+1] | rx_buffer[i] << 8);
if (lut[k] >= 4095) {
lut[k] = 4095;
}
}with the code bellow should the callback have a DMA specific function? is uint16_t size the correct value at the end.
Sorry, update to this; by changing the way I populated the rx_buffer in the while loop I have achieved the screenshots below. suggesting the issue still lies with how the rx_buffer is populated and not the transfer to the look up table.
while (1) {
if (mode == 0) {
if (rx_buffer[0] == 0) {
for (uint16_t i = 0; i < 4096; ++i) {
rx_buffer[i] = 7;
}
}
}
/ code /
}
payload had length 640, yet only the first 512 bytes of rx_buffer were populated (including [0]).
The LUT is correctly populated from the rx_buffer with uint16_t based on the uint8_t captured in rx_buffer. this stops working at the 254 value as the 5 start bits account for the remaining values to reach 512 bytes. Each subsequent value is populated as 0x0707=1799 all the way to 319 as requested.
