printf problem after startup of device

[predragn]

Hello

I'm facing with printf over uart problem in my app. Application based on uart example from SDK 15.2.

However, it happens that printf function prints message to uart while on debugger. After start-up every time the first printf miss to print something. After that, it works properly.

Do I miss something related to configuration? Is there a time limits when i can't send over UART or I need to flush some internal buffers before printf call? I dont have Idea where is the problem.

Every kind of help is welcome.

Best regards,

Predrag

[awneil]

predragn said:

the first printf miss to print something

What, exactly, do you mean by that?

[predragn]

I wasn't absolutely precise about that - thing is: I have implemented some commands that come over the same uart where the printf flushes it's stream. Now the problem is after startup - I send some command, wait for the answer that never happen that time. Next time I send same command i have expected answer sent back. No power off s between steps.

There is one more thing weird about that (take a look the code bellow): Explained situation happens when have some led togglings (based on nrf_delay_ms()); If put the printf above the Master_UsrLedsToggle() printf sends character stream normaly. If situation is that I have printf bellow the  toggling, i don't get the answer after startup.

if(CMD_BUFF[2]=='U'){
								Master_UsrLedsToggle();
								printf("LEDU ENTER\n");
						}

[awneil]

predragn said:

I send some command, wait for the answer that never happen that time.

So how do you know whether the problem is in the sending or the receiving?

Or both?

[predragn]

I use while (app_uart_get(&cr) != NRF_SUCCESS): to receive the message character by character, (meanwhile parse it). I have led indication to tell me the message is received,  and so on. So I don't think the problem is in receiving but if you think the problem is in approach that i showed (i took this approach from the example) you can suggest another way. Except these i have an Uart error handler. Imagine  https://infocenter.nordicsemi.com/index.jsp just without the loopback test and with logic for receiving and parsing the message character by character.

[awneil]

predragn said:

suggest another way

i suggest that you use a terminal or similar to see what is actually being sent.

Best to use something that shows the raw hex - so that you can see if stuff is getting corrupted.