0
\$\begingroup\$

I am using two stm32H7A3ZI-Q.
Both boards are used to generate data that is transmitted and received (IT) via UART to each other.

This data is used to as a variable to calculate a set of equations in both boards.
The data changes each cycle.

When printing the data via the serial comms into putty I get data for about 3 cycles then it turns to NANs.
I was wondering what could be causing this?

Key Updates.

  1. I am using a jumper cables between the boards to send the data.
  2. I am seeing nan's from the serial comms on putty.
  3. I have grounded the grounds between the boards.
  4. The image below is a section of what is getting printed enter image description here
  5. This is the code i am using to transmit and receive data enter image description here

I have solve my problem. Like a said earlier think they are out of sync, Tx, and Rx. They were i used the function below to solve the problem. void HAL_UART_TxCpltCallback(UART_HandleTypeDef *huart); void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart);

\$\endgroup\$
23
  • 2
    \$\begingroup\$ No ground then? You need one. Also, you really can't troubleshoot things like this without both an in-circuit debugger and an oscilloscope. Merely staring intently at the PCB won't solve anything... \$\endgroup\$
    – Lundin
    Commented Nov 24, 2023 at 13:40
  • 2
    \$\begingroup\$ "I thought the issue is that the boards could be out of sync" What does that even mean? UART is asynchronous. Each part obviously needs to use the same baudrate, but you say that some correct data is getting through, so that's not it. \$\endgroup\$
    – Lundin
    Commented Nov 24, 2023 at 13:46
  • 2
    \$\begingroup\$ "it turns to NANs" ... does this mean you see NAN in the UART output?... if so, I'd imagine this is nothing to do with the UART, and entirely to do with a floating point algorithm somewhere else. \$\endgroup\$
    – Attie
    Commented Nov 24, 2023 at 14:05
  • 1
    \$\begingroup\$ The code you posted has no relevance for the output posted. Where did those commas go? There's lots of fishy casts in that code. Or are you per chance posting the wrong code? Can you share more of the code in text format (not pictures of code)? \$\endgroup\$
    – Lundin
    Commented Nov 24, 2023 at 15:00
  • 1
    \$\begingroup\$ "nan" (not a number) is a very specific floating-point value. With few exceptions, it can only arise from invalid math operations such as division by 0 followed by addition, square root of negative number etc. Check your math calculations. \$\endgroup\$
    – Codo
    Commented Nov 24, 2023 at 22:06

3 Answers 3

4
\$\begingroup\$

Transmitting sizeof(txbuf) number of bytes is almost certainly a bug. The "nan" etc garbage likely comes from sending uninitialized parts of the buffer way past the null terminator generated by sprintf.

Instead you should be transmitting strlen(txbuf) number of bytes. Or alternatively strlen(txbuf)+1 if you wish to include a null terminator at the end of the UART data. (Since sprintf returns the number of bytes written, you could use that result as well.)

In addition there are lots of fishy casts and at least one of them is incorrect.

\$\endgroup\$
2
  • 1
    \$\begingroup\$ Since the sprintf() already returns the length of the string that was written to buffer, it's not very efficient to have an extra call to strlen() to go through the string again to find the length for the second time. \$\endgroup\$
    – Justme
    Commented Nov 24, 2023 at 18:01
  • \$\begingroup\$ @Justme True, but since sprintf is present in the code in the first place, the OP already threw performance out the window... \$\endgroup\$
    – Lundin
    Commented Nov 24, 2023 at 20:01
2
\$\begingroup\$

The nan output you see means "Not a Number" and can occur for a wide number of reasons when floating point numbers "go wrong". (nan can also be styalized as NaN or NAN depending on the libraries being used).

This isn't an error with the UART, but rather something to do with your algorithm and/or software.

Without a lot more detail about what you're doing and how, we can't possibly start to guess at what might be going wrong here, sorry.

This could be happening because you're writing past the end of a buffer (very possible given the snippet of code you've shared), or perhaps you're doing bad maths (e.g: x/0.0 or sqrt(-1)).

\$\endgroup\$
1
\$\begingroup\$

Your code starts data reception via interrupts, but immediately after starting the reception, even without receiving any data, you are trying to convert nothing that has been received into three floats.

So this is not a UART error. You are simply not converting any received data because you never wait for the data to be received.

Of course, impossible to say what your code does outside of those four lines of code.

\$\endgroup\$
2
  • \$\begingroup\$ Just FYI: it's a 'yoo-art', not an 'oo-art'. Same for USB, etc. \$\endgroup\$
    – brhans
    Commented Nov 28, 2023 at 16:22
  • 1
    \$\begingroup\$ @brhans Thanks, I should have known that better but I don't think I've ever given much thought to that, but I'll make an effort to try. The languages where e.g. letter "u" is always a wovel and is always spelled/pronunciated identically regardless of the context are so much easier :) \$\endgroup\$
    – Justme
    Commented Nov 28, 2023 at 16:41

Not the answer you're looking for? Browse other questions tagged or ask your own question.