UART example goes to debug window

[ProtonTim]

I have been developing some nrf52832 code (SDK 17.0.2) using the Segger RTT debug window for logging.  I added the code from the UART example but the printf goes to the debug window not the UART.

In my sdk_config file I have the following:

// NRF_LOG_BACKEND_SERIAL_USES_UART - If enabled data is printed over UART
//==========================================================
#ifndef NRF_LOG_BACKEND_SERIAL_USES_UART
#define NRF_LOG_BACKEND_SERIAL_USES_UART 1
#endif

// NRF_LOG_BACKEND_SERIAL_USES_RTT - If enabled data is printed using RTT
//==========================================================
#ifndef NRF_LOG_BACKEND_SERIAL_USES_RTT
#define NRF_LOG_BACKEND_SERIAL_USES_RTT 0
#endif

//==========================================================
// <e> NRF_LOG_BACKEND_RTT_ENABLED - nrf_log_backend_rtt - Log RTT backend
//==========================================================
#ifndef NRF_LOG_BACKEND_RTT_ENABLED
#define NRF_LOG_BACKEND_RTT_ENABLED 0
#endif

// <e> NRF_LOG_BACKEND_UART_ENABLED - nrf_log_backend_uart - Log UART backend
//==========================================================
#ifndef NRF_LOG_BACKEND_UART_ENABLED
#define NRF_LOG_BACKEND_UART_ENABLED 1
#endif

// <o> NRF_LOG_BACKEND_UART_TX_PIN - UART TX pin
#ifndef NRF_LOG_BACKEND_UART_TX_PIN
#define NRF_LOG_BACKEND_UART_TX_PIN 6
#endif

What else needs to be done to get the UART example to output on the UART and not on RTT?

Thanks for your help,

Tim

[Jared]

Hi,

Have you enabled the RETARGET config in the sdk_config file?: 

#ifndef RETARGET_ENABLED
#define RETARGET_ENABLED 1
#endif

You also need to add the path to retarget.c to the project.

regards

Jared 

[ProtonTim]

I switched on RETARGET_ENABLED and added retarget.c to the project.  Now it no longer directs the printf output to the debug window, but I don't see anything on the terminal.  When I run the uart example code on my hardware it prints to the terminal so I know the hardware is working and my pinout is correct.  Anything else I might be missing? Seems like it is still a config or library issue.

One more issue.  It looks like I cannot mix sending things out the UART with the example code AND sending logging messages to the RTT is that true?  I know it is not a hardware limitation but is it a code limitation of the library used in the UART example?  If so can you refer me to an example of how to use the UART independent of the logging?  I am thinking of just writing the low level drivers myself if necessary.

Thanks for your help.

Tim

[ProtonTim]

5657.sdk_config.h

[ProtonTim]

Jared,  I was able to get the printf to work.  Once I got the config right I had to add a delay to let the characters come out.  I am going to switch the logging back to RTT now.  Hopefully the printf and RTT logging will work together nicely as you noted.  Thanks for the help.

Regards,

Tim

[ProtonTim]

Jared,

The printf function works, but now my program does not!!  I have some nrf_delay_ms(100) in the program and it seems to lockup on those statements.  For instance I break on the red() function and then hit the step over button the debugger goes away.  When I hit pause I can see it is stuck in app_error().  None of this happened before adding the printf functionality. Do you know what I broke?

while(!pb_pressed()) // wait for button to be pressed to start test
{
red();
nrf_delay_ms(100);
green();
nrf_delay_ms(100);
blue();
nrf_delay_ms(100);
}

[ProtonTim]

Here is the call stack.  Not exactly sure what to make of it.

[Jared]

Hi,

 My guess is that it goes into the error handler in app_uart.c or app_uart_fifo.c. 

app_uart_event.data.error_communication is set in the error handler and will contain the value in the ERRORSRC register for the UART peripheral. Use the debugger and check what value this is set to.

Also, regarding the logging module, are you using deferred or in-place logging when you log over RTT? 

regards

Jared 

[ProtonTim]

I found the issue.  When I configure the I2S port with nrf_drv_i2s_init() the ERRORSRC for the UART gets set to 0xC.  Why would the I2S effect the UART?  Do they share resources?  How can I make them play nicely together? 

Thanks,

Tim

[Jared]

Hi Tim,

They do not use the same resources as shown by the instantiation table. Could it be a pin conflict, are they assigned to use the same pins?

regards

Jared 

[ProtonTim]

Jared, it is indeed a pin issue but it seems like a bug.  The error happens in nrf_i2s_pins_set when I the library function tries to set the SDOUT pin to 0x255, which should mean unused.  When this value is written to the PSEL.SDOUT register the UART error is thrown.  To me it looks like a bug?  What might I be doing wrong?

__STATIC_INLINE void nrf_i2s_pins_set(NRF_I2S_Type * p_reg,
uint32_t sck_pin,
uint32_t lrck_pin,
uint32_t mck_pin,
uint32_t sdout_pin,
uint32_t sdin_pin)
{
p_reg->PSEL.SCK = sck_pin;
p_reg->PSEL.LRCK = lrck_pin;
p_reg->PSEL.MCK = mck_pin;
p_reg->PSEL.SDOUT = sdout_pin;
p_reg->PSEL.SDIN = sdin_pin;
}

Here is my code that preceeds the above library function, as you can see I am setting the pin to unconnected, and indeed in the nrf_i2s_pins_set function it seeks to set the pin value to 0x255.  I am befuddled.

uint32_t config_I2S()
{
nrf_drv_i2s_config_t config = NRF_DRV_I2S_DEFAULT_CONFIG;
// In Master mode the MCK frequency and the MCK/LRCK ratio should be
// set properly in order to achieve desired audio sample rate (which
// is equivalent to the LRCK frequency).
config.sdin_pin = DIN_PIN;
config.sdout_pin = NRF_I2S_PIN_NOT_CONNECTED; // This pin is not used
config.mck_setup = NRF_I2S_MCK_32MDIV3; //MCLK 10.666667MHz
config.ratio = NRF_I2S_RATIO_256X; //LR clock (WCLK) 41.6667KHz
config.channels = NRF_I2S_CHANNELS_LEFT; // Use only the right channel (comes in on the left?)
config.mode = NRF_I2S_MODE_MASTER;
config.sample_width = NRF_I2S_SWIDTH_16BIT;
config.format = NRF_I2S_FORMAT_I2S;
//config.format = NRF_I2S_FORMAT_ALIGNED;
config.lrck_pin = WCLK_PIN;
config.mck_pin = MCLK_PIN;
config.sck_pin = BCLK_PIN;

uint32_t err_code = NRF_SUCCESS;
err_code = nrf_drv_i2s_init(&config, data_handler);

return(err_code);

}

[Jared]

Hi,

This seems strange. Have you reproduced this on a development kit? What happens if you assign the SDOUT pin to a physical pin, still getting an error from the UART driver? 

regards

Jared 

[ProtonTim]

Hi Jared,

Sure enough everything works fine when I assign SDOUT to an unused physical pin (pin 9).  But when I assign it to the unused (0xFF) it sets the UART error flag as described.  I really don't want SDOUT coming out so it would be nice if there was a fix for this.