UART transfer problem with PC

[h267947]

Posted on June 27, 2016 at 23:47

Greetings everyone.

I am in the early stage of the development of a data acquisition software, still getting familiar with STM32 (read through the reference manual, datasheet and many appnotes). I have written a test program which basically does the following: the ADC measures the fixed DAC output (which is looped back with a cable on the board), it fills a buffer through DMA with 4096 16 bit samples (the CPU is sleeping during the measurement), once done, the DMA starts transferring the samples to USART6 (again the CPU is in sleep during this), which transfers the data to a LabView visualization/statistical program on PC with 115200 baud/s speed. After the transfer is complete, the process starts over. The problem is the following: as it turned out, the byte order appears swapped between consecutive buffers on the PC. So for example, when measuring fixed 0x03E8 DAC output, one buffer (4096 samples) is received correctly, then the next buffer is received full of 0xE803 samples, then the next buffer is correct again etc. I'm swapping the bytes for every even numbered buffer in LabView, but sometimes it is the odd numbered buffers which are wrong, so this isn't a real solution. I have tried several things to fix this, including messing around with FIFO to achieve a proper halfword->byte memory-to-peripheral transfer (in case it's wrong), slowing down baudrate, slowing down ADC clock, using other USART peripherals etc., none have changed the situation. During debugging, the buffer always appeared to store the correct conversion values but they were somehow transmitted wrong, and the error callback functions didn't report any error for ADC or USART. I am using the STM32F4DISCOVERY board, OpenSTM32 IDE for development, a C232HD-DDHSP-0 FTDI cable for communication, and LabView 2013 on Windows 7 on the PC. I am enclosing the code of the main file and the MSP file. I have already done similar work with another MCU family and company with no problems, this is why I think that the problem is not on the PC side. Thanks for your help. #stm32-uart-dma-adc-labview