Receive external data through UART on Thingy:91

[T1mS_]

Hi,

For my project I need to receive 9 bytes of data from our main board. This data gets send using UART. 

By looking at the pin diagram I could not find specific pins on the Thingy:91 to use as UART RX and TX.

So my question, are there any GPIO pins capable of handling an UART connection?

And if yes, which are they and last but not least how the code would look like.

Thanks,

Tim

[Håkon Alseth]

Hi,

 

The Thingy:91 is limited in terms of GPIOs available.

The UART pins, marked with "MCU_IF0" to "MCU_IF7" are directly wired to the nRF52840, as the nRF52840 acts as a USB-to-UART bridge in this case.

 

If you need a more flexible solution in terms of GPIOs, I would recommend that you look at the nRF91-DK instead.

 

Kind regards,

Håkon

[Marc]

Hi Hakon

I have the same need for an UART on the Thingy:91 like T1mS_. I have a SW running on the nRF91-DK communicating over UART_1 with an external controller. Now for the Proof of Concept I need to show a miniaturization for which I want to use the Thingy. I could think of two options:

Option 1:
Use two lines of the UART-USB bridge MCU_IF3-7 (P0.21-25), cut the according solder bridges (SB7-11) and connect the wires directly to one pad of the solder bridges. 
For this I just need to know if and which two lines of IF3-7 would be available? Since the Modem Trace is not yet available (and I don't need it) I rekon I could use these lines. I want still to be able to see the debug log on the UART over USB however.

Option 2:
TP7 is connected to P0.10 and has an already open solder bridge (SB5&6). Thus, It seems P0.10 is not used and I could use it for the UART_1 RX? One RX is the minimum I need. Or do you see another option for the TX line too? Maybe TP36 (P0.05) which seems not to be connected to the SPI:MISO?

Thx!

Marc

[Håkon Alseth]

Hi Marc,

 

Marc said:

For this I just need to know if and which two lines of IF3-7 would be available? Since the Modem Trace is not yet available (and I don't need it) I rekon I could use these lines. I want still to be able to see the debug log on the UART over USB however.

If you cut the trace, and connect to the "nrf91" side, they're all available, as long as you have not enabled modem tracing.

As a generic note, the CTS and RTS are not used, so they're free to use even when both UARTs are running.

 

Marc said:

Option 2:
TP7 is connected to P0.10 and has an already open solder bridge (SB5&6). Thus, It seems P0.10 is not used and I could use it for the UART_1 RX? One RX is the minimum I need. Or do you see another option for the TX line too? Maybe TP36 (P0.05) which seems not to be connected to the SPI:MISO?

Yes, you're right wrt. P0.10. You can also hook into either SB5 or SB6 to get to P0.10. But, you are going to be short one GPIO here, as P0.05 goes to ADXL362 and ADXL372.

 

Kind regards,

Håkon

[Marc]

Hi Hakon

Thx for your answer. I did option 1 and it's working fine! :-) How the lines IF3-7 are used, i found in the nrf9160_pca20035_common.dts file. I just used an overlay file like this to my needed speed of uart1

nrf9160_pca20035ns.overlay

&uart1 {
	current-speed = <115200>;
	status = "okay";
	tx-pin = <22>;
	rx-pin = <23>;
	rts-pin = <24>;
	cts-pin = <25>;
};

Thx for the general note, that CTS and RTS are not used anyhow.

I did not try option 2.

BR

Marc

[Håkon Alseth]

Marc said:

Thx for your answer. I did option 1 and it's working fine! :-) How the lines IF3-7 are used, i found in the nrf9160_pca20035_common.dts file. I just used an overlay file like this to my needed speed of uart1

 Glad to hear that you got things working!

 

Marc said:

Thx for the general note, that CTS and RTS are not used anyhow.

 My apologies here, while the flow control (ie: the UART register setting) is enabled by "UART_0_NRF_FLOW_CONTROL=y" (change 0 to 1 or 2, if using UART1 / UART2), it seems that the nRF9160 sets the GPIOs as the respective output / input, with the default level set. Not a huge problem, but it reconfigures the GPIO pins, which could be problematic for some designs.

If you set the rts-pin = <0xFFFFFFFF>; and cts-pin = <0xFFFFFFFF>;, they should not be re-configured at all.

 

I'll report this as a bug internally

 

Kind regards,

Håkon