nRF5340DK arduino serial port doesn't work

[KentH]

I am porting an application from a nrf52840DK -> nrf5340DK and can't make the Arduino serial port work. I am using sdk v2.6.0.

My working development environment uses two 52840DKs and connects the arduino serial ports on the two boards (arduino pins D0/D1/D2) swapping D0/D1 (Tx/Rx) in the cable. I swapped one of the nrf52DKs for a nrf5340DK and the boards wouldn't talk. I am monitoring the communications with a data scope & notice that when I use a nrf53DK,  polling messages from the other DK stop (like the signal was shorted). When I switch power off on the nrf53DK, the polling resumes.

Also I notice that the control signal (arduino D2) is asserted for nrf52DK, but deasserted for nrf53.

I am using a minimal overlay file which assigns some flash0 partitions in the external flash and creates an alias "{ z9io-serial = &arduino-serial; };"

In the nrf53 overlay I added "&i2c1 { status="disabled" };" based on a warning in the device tree viewer.

My interface cable connects to the dual 0.1 header I soldered into P15. I can make new cables if the arduino serial port is unavailable on the nrf53DK.

Thanks for your help. Normally device tree changes just work -- so I'm not sure how to debug this.

And BTW: I couldn't find the nrf5340DK schematic. A pointer to that would also be appreciated.

Kent

[Jørgen Holmefjord]

Hi,

My working development environment uses two 52840DKs and connects the arduino serial ports on the two boards (arduino pins D0/D1/D2) swapping D0/D1 (Tx/Rx) in the cable. I swapped one of the nrf52DKs for a nrf5340DK and the boards wouldn't talk. I am monitoring the communications with a data scope & notice that when I use a nrf53DK,  polling messages from the other DK stop (like the signal was shorted). When I switch power off on the nrf53DK, the polling resumes.

Also I notice that the control signal (arduino D2) is asserted for nrf52DK, but deasserted for nrf53.

It is possible that the pins are assigned to the serial port on the network core, if you are building a sample that uses a child image (for instance a Bluetooth sample). By default, P1.00/P1.01 are used for one of the UART ports on the DK, and these pins are assigned both to UART0 on network core and UART1/arduino_serial on application core. Can you try different pins?

And BTW: I couldn't find the nrf5340DK schematic. A pointer to that would also be appreciated.

Hardware files are available for download here: https://www.nordicsemi.com/Products/Development-hardware/nRF5340-DK/Download?lang=en#infotabs 

Best regards,
Jørgen

[KentH]

Thank you for your reply. My application does include bluetooth functionality so I imagine the network core is also activated. (which I think should be expected for a nRF53 application). So is it expected that the network core will always take the "arduino-serial" port and not leave it available for the application core?

While this particular application is using the nrf-DK  "ardiuino-serial" ports for board-to-board communications (which means I can reassign the nrf53DK port), I also use the nrf-DKs  to develop drivers for chips which have "arduino-format" development kits for the chips. While most of these part DKs use SPI or I2C interfaces, some use the arduino-serial port. Are these DKs just not compatible with the "arduino connector" on the nrf5340DK because the network core has claimed the serial port first?

 One other question I had was why the device-tree viewer for the nrf5340DK application-core shows a conflict between the "i2c1" and the arduino serial port that required me to disable the i2c1 in my application overlay? In fact the device tree overlay showed several conflicts with an overlay that just referenced the arduino port via an alias. I am new the the nrf53, but don't recall any conflicts in the nrf52840DK device trees.

And thank you for your answer and the link to the schematic.  

[Jørgen Holmefjord]

KentH said:

So is it expected that the network core will always take the "arduino-serial" port and not leave it available for the application core?

It is not that the network core takes over the "arduino_serial" port (which is just an alias for uart1 instance in nRF5340, but by default, the uart0 instance in network core is assigned the same pins as the uart1 instance in application core. Since these pins are connected to the interface MCU (debugger chip) on the DK, it can provide Virtual COM port functionality between the USB connector and the serial instances on both cores, typically used for logging. When the child image is built for the network core, the GPIOs are assigned to the network core and can't be used by the application core. You should still be able to use uart1 (arduino_serial) on different GPIOs if you change these in an overlay file, or you can change the GPIOs used by network core for uart0 instance using an overlay for the child image.

KentH said:

While this particular application is using the nrf-DK  "ardiuino-serial" ports for board-to-board communications (which means I can reassign the nrf53DK port), I also use the nrf-DKs  to develop drivers for chips which have "arduino-format" development kits for the chips. While most of these part DKs use SPI or I2C interfaces, some use the arduino-serial port. Are these DKs just not compatible with the "arduino connector" on the nrf5340DK because the network core has claimed the serial port first?

Again, the arduino_serial node is just a label for the uart1 node, which simplifies usage of the DK together with the samples in Zephyr that references the arduino-serial/spi/i2c nodes. You could also use an overlay to assign the sensor to another serial instance in your devicetree if you use a board without the arduino-nodes.

The arduino-serial node is also not claimed by the network core, this is just the GPIOs that are assigned to arduino-serial by default.

KentH said:

One other question I had was why the device-tree viewer for the nrf5340DK application-core shows a conflict between the "i2c1" and the arduino serial port that required me to disable the i2c1 in my application overlay?

Some of the serial instances in nRF5340 shares the same resources, which can be seen by the overlapping base address in Peripheral instantiation. You can only assign one serial protocol to each serial instace, which means that if you enable uart1 (arduino-serial) in your devicetree, you need to disable spi1 and i2c1 nodes to avoid conflicts.

KentH said:

I am new the the nrf53, but don't recall any conflicts in the nrf52840DK device trees.

The same conflicts can occur in nRF52840, but here only SPI(M)/TWI(M)/SPIS/TWIS share the same instances, UARTE0 and UARTE1 are on separate base addresses and can always be used.

[KentH]

This clears everything up for me. Let me summarize to be sure I understand.

1. the nrf5340 DK "console" port for the network core (out-of-the-box) uses the same pins as the arduino-serial tx/rx.

2. for my board-to-board application, I should use another set of pins: eg Arduino D14/D15/D18 (P0.00, P0.01, P0.07) and solder my pin header on P17.

3. If I need the "arduino-serial" uart channel on the arduino footprint, i need to electrically disconnect the "network console" by operating switch S7-B on the nrf5340DK and/or break the appropriate solder-beads. I would also need to "logically" disconnect the port from the network core (so the application core could access the arduino-serial port) by using your instructions above to create a child image overlay (or kconfig fragment?) to disable the network console.

4. Alternately, if I need the "arduino-serial" interface to develop a driver, I should just use a nrf52840DK and call it a day.

Thanks for your help. These DKs support many uses, and it wasn't obvious to me how to solve my use case.

Kent

[Jørgen Holmefjord]

KentH said:

1. the nrf5340 DK "console" port for the network core (out-of-the-box) uses the same pins as the arduino-serial tx/rx.

Correct!

KentH said:

2. for my board-to-board application, I should use another set of pins: eg Arduino D14/D15/D18 (P0.00, P0.01, P0.07) and solder my pin header on P17.

Yes, this might be simpler than remapping the default pins used by the network core for every application.

KentH said:

3. If I need the "arduino-serial" uart channel on the arduino footprint, i need to electrically disconnect the "network console" by operating switch S7-B on the nrf5340DK and/or break the appropriate solder-beads. I would also need to "logically" disconnect the port from the network core (so the application core could access the arduino-serial port) by using your instructions above to create a child image overlay (or kconfig fragment?) to disable the network console.

Yes, this would be the best approach. It might work without physical modifications to the DK as well, as long as no terminal on the host have connected to the virtual com port and the Network core have disabled the UART instance or assigned other pins.

KentH said:

4. Alternately, if I need the "arduino-serial" interface to develop a driver, I should just use a nrf52840DK and call it a day.

This would also work, but the "users" of the driver might face similar issues if using the driver on nRF5340DK.

Best regards,
Jørgen