Failure receiving usart signals on one scenario and not the other.

[Kamurasi-Jordan-Arthur]

Hey there community, 

I am having trouble fixing an interesting scenario on Usart communication,
With the same software doing a reception on a given usart interface, It has been noticed the reception segregates one connection but not the other, Both connections having the same configuration

It has been tested that the board on which it fails has connection on that line and that the connection actually reaches the intended pin for sure by testing the Usart Rx pin when set up as a both a GPIO input and latter as an output.

by playing with this GPIO input and output mechanisms on that pin. and observing respectively from both the led toggles on the board intended to signify sign of life on the pin and, logic analyzer to see the GPIO state when toggled from with in the system.

Note, we are able to see the usart signals on both and are able to decode the messages on a logic analyzer for both, but the stm does not receive the message on one connection.

We appreciate any insight into the Issue

[TDK]

> the reception segregates one connection but not the other

What does this mean?

Be specific, show code. Rely on example code if you don't want to share your own.

[Kamurasi-Jordan-Arthur]

Hello, 
"> the reception segregates one connection but not the other" means that if the software is run on one board the, The reception of data from the other side, works okay, but When run on the other, It fails. 
Note the boards are custom made and we trying to do Bring up on then, 
Also the connection is actually there for the board that fails. and the data has been decoded using a logic analyser, To add the signal actually reaches the pin when set up as an ExTI GPIO pin. 

 Also the Only difference is that the Transmission is from two different modules, one Is a UE version and the other a global, But again the signals on both are decoded with a logic analyzer.

Sorry If I was not specific enough.
I will share my code snippet.

In the shared code

HAL_UART_Receive_IT(&huart4, &rx1_byte, 1);

the interrupt for one never fires.


  

[Andrew Neil]

As @TDK said, you need to give more details:

How to write your question to maximize your chances to find a solution

How many boards are involved here - how many receivers? how many senders?

And what combinations work/fail ?

---

@Kamurasi-Jordan-Arthur wrote:

the reception segregates one connection but not the other,

---

I also don't understand this.

---

@Kamurasi-Jordan-Arthur wrote:

the stm does not receive the message on one connection.

---

Are you sure that it doesn't receive it at all ?

Maybe it does receive it, but ignores it - perhaps due to errors ?

Have you used the debugger to see what's going on?

Some tips on Debugging Serial Comms.

A possible reason could be that your baud rates are inaccurate - one is (only just) within limits; the other is (only just) outside...

Remember it's the total baud rate error - the combination of both sender error and receiver error - that matters...

[Kamurasi-Jordan-Arthur]

Hey there ounce more, 

Yes we have do debugging and we intend to catch any errors during the debug Session.
"the stm does not receive the message on one connection", I mean the stm32n6 mcu (STM32N657X0HxQ) usart3 rx line does not receive usart signals when connected to a global LTE module, but does receive messages when connected to a EU version of the lte. the usart configuration for both the LTE versions are the same.

A colleague of mine will hope in to shade more light on the matter.

[Andrew Neil]

Still unclear on whether that's just one N6 board that doesn't work, or several ?

And whether you have just one of each LTE module, or several.

Again, marginal specs - particularly baud rates - could be an issue.

Are you using a good, stable, crystal source for your baud rates?

Can you reproduce this on an ST board?

Have you tested the LTE modules against known-good hosts?

Have you tested your N6(s) against a known-good device - eg, serial terminal?

[Kamurasi-Jordan-Arthur · Accepted solution]

Hellos all,
After a series of trials:
I find that the Global variant of the LTE modem has its replies faster than the EU variant.
This is also the case for the first "RDY\n" message that comes out when the LTE is powered up.

My code:

void lte_test(void){
  //
  MX_USART3_UART_Init();

  //Power the LTE
  HAL_GPIO_WritePin(LTE_PWR_EN_GPIO_Port, LTE_PWR_EN_Pin, GPIO_PIN_SET);
  HAL_Delay(50U);
  HAL_GPIO_WritePin(LTE_PWR_KEY_GPIO_Port, LTE_PWR_KEY_Pin, GPIO_PIN_SET);
  HAL_Delay(500U); // WAIT FOR 500MS BEFORE RELEASING
  HAL_GPIO_WritePin(LTE_PWR_KEY_GPIO_Port, LTE_PWR_KEY_Pin, GPIO_PIN_RESET);

  HAL_GPIO_WritePin(LTE_DTR_GPIO_Port, LTE_DTR_Pin, GPIO_PIN_RESET);

  // HAL_GPIO_WritePin(LTE_PWR_EN2_GPIO_Port, LTE_PWR_EN2_Pin, GPIO_PIN_SET);
  // HAL_Delay(50U);
  // HAL_GPIO_WritePin(LTE_PWR_KEY2_GPIO_Port, LTE_PWR_KEY2_Pin, GPIO_PIN_SET);
  // HAL_Delay(2000U);
  // HAL_GPIO_WritePin(LTE_DTR2_GPIO_Port, LTE_DTR2_Pin, GPIO_PIN_RESET);

  /* Start reception of 1 byte on each UART */
  HAL_UART_Receive_IT(&huart1, &rx3_byte, 1);
  HAL_UART_Receive_IT(&huart4, &rx1_byte, 1);

basically I was enabling interrupts before calling the reception using interrupts,  and adding some delays also,
hence I was locked out from any more reception until the interrupt that fired first had been cleared.

---

Edited to apply source code formatting - please see How to insert source code for future reference.