I am attempting to add a UART to interface to an external MCU. I have the uart example running (without any RTT info) yet when I port the uart code to the ble-thread example I am not getting any data out the TX pin, I am getting data from the RX pin. What am I missing? Is the RTT messing with the transmitting of UART data?
Is the RTT messing with the transmitting of UART data?
If you are using the same UART pins for RTT and your UART interface, they most likely are interfereing.
Please check the URAT pins used by the RTT in the sdk_config.h file (
I do not have that defined in the sdk_config file. I am use the nrf52840 dev kit and SES. RTT and NRF_LOG_ENABLE are set.
can you double check if app_uart_put is being executed by the CPU? I mean can you run this in a debugger after your put a breakpoint at app_uart_put.
I just want to make sure if there are any configuration in your system that is masking it to execute? If it does execute then you can step in app_uart_put to see if the write to the UART_TXD register has no effect on pins? If that is the case then something must definitely conflicting with the uart configuration.
I am helping Mike work on this problem. I followed Mike's guidance and created a project that matched his and duplicated the hard fault. But then I wondered if I could debug the "ble_thread_dyn_hrs_coap_freertos" example that Mike is using as his starting point and this project without modification also Hard Faults when I attempt to debug it. So, it appears to have nothing to do with the addition of the UART. At least the Hard Faulting doesn't.
I'm looking at the UART code separately, but am confounded that the example cannot be debugged.
I tried a couple more multiprotocol examples. Is this related to debugging with the soft device running?
I tested the UART code in isolation and it appears to work just fine. I don't see a functional problem with it.
Does this have anything to do with this thread:
https://devzone.nordicsemi.com/f/nordic-q-a/45065/thread-networking-in-nrf52840-dongle
Which leads to this file:
which is a precompiled part of the Thread stack which may directly interfere with what Mike is attempting here?
Is UART0 taken always by the Thread stack? Should we then use UART1 and to use UART1, use the Serial driver?
matt.heins said:Is UART0 taken always by the Thread stack? Should we then use UART1 and to use UART1, use the Serial driver?
Good catch Matthew. UART0 is reserved by thread, here is more info on this
matt.heins said:Is UART0 taken always by the Thread stack? Should we then use UART1 and to use UART1, use the Serial driver?
Good catch Matthew. UART0 is reserved by thread, here is more info on this
