The S32K312 UART+DMA+IDLE No matter which UART sends, data is sent as 0

[guochuan]

hi all

We are debugging S32K312 using UART+DMA+IDLE mode. The received data is normal, and the received data can be seen in idle interrupt. But the send data was 0. The tracer found that the DMA send completed the callback return was a success.

DMA tx config

DMA CHANNEL CONFIG

Test result: No matter which UART sends, the data sent is 0

[WellsonGuo]

I have the similar problem, but my situation is on the received side :
1. UART1(DMA) <----- UART3(Interrupt)

2.the sequential data received by UART1 DMA would be inserted a lot of unknown null termination '\0'.

ex : hello word\r\n \0 \0 \0 \0 \0 .... hello w \0 \0 \0 \0 hello...

3. I have also checked the status of DMA destionation address, and the address is normally shifted byte by byte by DMA hardware.

-> Dma_Ip_GetLogicChannelParam(UartUserCfg->RxDMAChannel, DMA_IP_CH_GET_DESTINATION_ADDRESS, (uint32*)&TmpDestBuf);

During this process of DMA transmitting, there is no '\0' be found on logic analyer.

4.these code flows have no problem on UART1 interrupt mode

I'm stuck with this problem for one week...

please give me some suggestions, thx. 

[WellsonGuo]

#pragma GCC section bss ".mcal_bss_no_cacheable"

uint8_t buffer;

#pragma GCC section bss

WOW, this is the root cause indeed,

thanks a lot!

[danielmartynek · Accepted solution]

Hi @guochuan,

Can you put the buffer to the non-cacheable section?

#pragma GCC section bss ".mcal_bss_no_cacheable"
uint8_t buffer;
#pragma GCC section bss

Thanks,

BR, Daniel

[guochuan]

Hi @danielmartynek 

thank you reply.

• I tried to put the variabler to the non-cacheable section with the operation you recommended, and the data was still sent to 0.

• Please help solve it, thank you

test result:

[danielmartynek]

Do you see any DMA or LPUART error flags?

Can you check the lpuartStatus code after the do-while loop?

[guochuan]

hi @danielmartynek 

thank you reply.

Using DMA to send tests, the results returned were successful. But the data sent out is all zeros.

• The DMA configuration is the upstairs picture

[danielmartynek]

If you can see all the 50 bytes (0x00 with correct Start / Stop bits) on the TX line, can you check the DMA descriptor in register view? Does it points at the correct address of the buffer in SRAM?

Can you share the project?

Regards,

Daniel

[guochuan]

hi @danielmartynek 

thank you reply.

Yes, The DMA status and  UART status is normal all. The project is fixed to send 50 bytes full of 0. share the project, please help to guide, thank you..

[guochuan]

hi @danielmartynek 

sorry  .The above attachment was uploaded incorrectly. The attachment was uploaded again.

thanks

[danielmartynek]

Hello @guochuan,

I really dont's see what the issue is.

The TX buffer consists of 50 bytes (all 0x00) and the LUART sends 50 bytes of 0x00.

I sent you a private message a week ago, but you haven't responded.

BR, Daniel

[guochuan]

hi @danielmartynek 

thank you reply.

sorry Unable to reply due to maximum private messages.

No, when I receive any data in the cache, I send 50 bytes of data with a fixed length, and the external listener finds that all zeros are sent out.

I have verified according to the routine you provided, and the phenomenon is the same. This problem has been troubling me for a long time, please help to solve it, thank you.

I have shared my demo, could you please verify it on my basis, I find that many developers encounter the same problem.

[danielmartynek]

Why don't you put all the buffers into the .mcal_bss_no_cacheable section?

As far as I see, the DMA receives the data to

uart0_DMA_recv_buffer & uart1_DMA_recv_buffer that are cacheable.

Then, the CM7 core copies the data to uart1_DMA_recv_bufferx that is not cacheable.

I mean, the core can copy the data from the cache (all 0x00) not the SRAM to uart1_DMA_recv_bufferx.

BR, Daniel

[guochuan]

hi @danielmartynek 

Is the demo I provided verified,Please help verify and guide what is abnormal.

thanks