Getting different value in buffer than expected from Oscilloscope.

[Divesh Dutt]

Hi Guys i am trying to get the data from lidar which works on UART and i am using interrupt to get the data value but i am not getting the acc to datasheet of lidar i am using HAL_UART_Receive_IT(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size); function to fill my buffer here is the datasheet screen shots

and yes i am using 115200 baud rate.

[Tesla DeLorean]

Ok, table should still be an array of uint8_t not uint16_t

[Divesh Dutt]

Do you guys think if that is synchronization problem? I am thinking this way and there is no change if i change it to uint8_t i am still getting the other value?

[Bob S]

Well, show us what data you DID receive (in your now 8-bit buffer). And if you do another scope capture, set your triggering to FALLING edge (the start bit begins with a high to low transition). It won't make a significant difference based on the scope images you've already posted, but triggering on the correct edge may save you same grief in the future.

[Tesla DeLorean]

The 0x59,0x59 pattern is there for you to do the synchronization against. Don't expect every time you request data from the UART it will be aligned. I'd probably use other methods to buffer via interrupt, the HAL is too clunky.

[Divesh Dutt]

these are the data i am getting and Clive what would you suggest me not to HAL library?

[Bob S]

I think what Clive is referring to is that the HAL library does not allow for continuous reception, at least not using the interrupt transfer. And it throws LOTS of code into your program that you may not need or care about.

That said, what you have is what you have so we'll work from that. You have not shown us your code, so we can only guess at what it is doing. Things to look for:

• Are your clocks really at the frequency you expect them to be?
• Are your USART settings what you expect them to be? In your debugger, read back the USART config registers and compare the values with the data sheet. Specifically baud rate divisor, number of bits, etc.
• Transmit data from the same USART that the lidar is connected to and look at the TX line (from the STM32) on the scope. Does the bit timing look correct for 115200 baud? This *should* be the case as one set of data you showed before seemed to have the 0x59 sync bytes in it. But best to verify this.
• Does the lidar unit continually send data? Or does it only send data when you ask for it? If it continually sends data, is there a pause between "packets" of data, or is it a continuous stream of data?

One issue with using the HAL functions is that each call to HAL_UART_Receive_IT() enables the USART, receives data, then DISABLES the USART. So any data send from the lidar between calls to HAL_UART_Receive_IT() are lost. And if the data is continuous with no pauses between any bytes, it is possible that you start reception in the middle of a character, and your USART either takes a berw bytes to synchronize to a real start but, or it never really synchronizes, so you see bogus data. This may not be likely, but is possible.

If possible, use a USB-to-serial converter in place of the lidar unit, connect it to a PC and use some terminal emulator (PuTTY, TeraTerm, etc.). Type KNOWN DATA on the PC and see what your software receives. Once you can receive good data this way, go back and try the lidar unit.

[Tesla DeLorean]

RealTerm has a HEX mode which might be helpful in this context.

I've posted L4/F7 based GPS code using a streamed USART interrupt method.

Configure the USART, pins and interrupts with the HAL, but have the IRQ handler check the registers directly, and either buffer the incoming data, or manage/sync via a state machine.

Sorry don't have this lidar unit so not heavily invested in a solution. I could build a demo framework for the F3, but this would run you several hundred dollars.

Your 16-bit code had values showing 0x5959 reception, so the hardware should be capable, the number of NULs in your data stream looks rather odd, the high state on the USART_RX pin between data bursts shouldn't produce nulls/noise.