Hello !!! Some strange error occured when I've tried to transfer a block data. First, Ithe processor received (by serial-DMA) 2006 bytes each time and this is repeated for 240 times resulting an array of 480,000 bytes

[INaka.1]

The processor is the STM32L4R5 and the SMT32CubeIDE versin 1.6.

uint16_t US_Cksum,Trans_Pointer,USA_Data[2006],US_Trans[480000];

uint32_t US_Pointer;

US_Pointer is zeroed at the start of the program

US_Cksum=0;// For Checksum

Trans_Pointer=4;

  while(Trans_Pointer<2004){

  US_Trans[US_Pointer]=USA_Data[Trans_Pointer];

  US_Cksum+=USA_Data[Trans_Pointer];

  US_Pointer++;

  Trans_Pointer++;

}

The question is: Why the US_Cksum doesn't generate a correct sum?

Thank you

[MM..1]

When your MCU have 640K RAM you cant store 480000 16bit values result is overmemory.

Too your pointer counter and code dont doo what you write.

[INaka.1]

I'm sorry. I wrote incorrectly the declaration. Indeed the correct declaration is : uint8_t USA_Data[2006],US_Trans[480000]. So, there´re space in RAM for others variables.

[waclawek.jan]

> Why the US_Cksum doesn't generate a correct sum?

How do you know it's not correct? To what do you compare it?

JW

[INaka.1]

Thank you for reading my question.

I forced a known buffer ( indeed I wrote 0x01 in all positions) so the Check sum must be 2000d ( or 0x07d0). I´ve looked the entire buffer, verifying if it was correct. But the Check Sum value isn´t.

[TDK]

There isn't a error in the hardware with adding numbers together.

Perhaps the code does not do what you think it does. Given you've mistyped uint16_t for uint8_t, seems like other parts of the code could also be wrong. Produce a minimal compilable example which exhibits the problem.

This is something you can very easily step through the code to verify it's adding 1 (in your forced buffer example) on each iteration. Reduce the buffer size and test. If you expect 0x7D0, What value do you get instead?

Less likely issues would be something not marked as volatile which should be.

[INaka.1]

Good morning. I wrote wrongly in the question uint16_t for the arrays. Indeed in the program is written correctly as"int8_t". Perhaps, this error occurs when I receive the buffer using the DMA-USART. I did the test with 100 bytes. When I forced a known buffer, the check sum is calculated correctly. But, when a receive this buffer through DMA- USART, the buffer is correct, but the check sum has a strange value.

Thank you for your attention.

[MM..1]

When buffer is ok then your code calculate checksum on bad time, with DMA you need wait for transfer complete because USART is slow ...

[INaka.1]

But, I'm waiting for the DMA interruption . I thought that this interruption occurs only when the specified amount of bytes are received -HAL_UART_Receive_DMA(&huart1,USA_Data,2006); Am I wrong ?

[INaka.1]

Well... you're absolutely right. I put a delay ( HAL_Delay(100) after the interruption response. Then the Checksum is correct. Now, I need to discover how much time I need to wait.

Thank you very much

[Tesla DeLorean]

>>But, when a receive this buffer through DMA- USART, the buffer is correct, but the check sum has a strange value.

Math or data is wrong.

>>Now, I need to discover how much time I need to wait.

Doesn't the UART DMA have a call back that indicates the last byte was received.

Flag that in a volatile variable, and wait on it, or do the checksum/dispatch in the call-back..

[MM..1]

Maybe you dont understand DMA

HAL_UART_Receive_DMA(&huart1,USA_Data,2006); Am I wrong ?

is only start operation , this not wait to data end , DMA is for MCU offload then code continue immediately and no data is received at that moment.

Your code here can do other things and Cortex provide two IRQ one for half buffer received and second for full buffer.

In this two IRQ callbacks you need move data calc anything usw.

[INaka.1]

Hello my friend... You know, I'm a beginner with STM32. What i do is prepare the DMA UART receive interrupt and wait for a interruption inside the" stm32l4xx_it.c". I didn't know that the DMA provides two interruption. Then now, I´m waiting for the second ( full buffer) and it worked properly.

Thank you again for the help!!!

Best regards.