UART not working on nrf52840

[deadprogram]

UART not working on nrf52840

[aykevl]

Nothing seems obviously wrong when looking at the code.
You can take a look at the UART section in the datasheet, maybe there's something different from the other two chips (nrf51, nrf52832): http://infocenter.nordicsemi.com/pdf/nRF52840_PS_v1.0.pdf
I don't have the hardware itself so it's hard for me to debug it.

[deadprogram]

Understood. Any ideas on how I might go about debugging it myself?

[aykevl]

Things you can try:

• If GDB is working, you can see whether it is doing what you expect: replace 'flash' with 'gdb' in the tinygo command. Stop the currently running program with Ctrl-C. If it sleeps, it should be at the for !rtc_wakeup { line. The regular bt command works for the most part so you can see a backtrace. If it crashed, it might point out the exact location where it did.
• If you don't have GDB, you can simply try to blink an LED every time you write something to the UART, to make sure the program didn't crash.
• If you have one, you can hang a logic analyzer or scope directly on the uart tx pin. If not, try connecting an external UART-to-USB converter. Maybe it does send data but something else doesn't work properly.
• You can also try running something else on the device that writes to the UART, to make really sure everything works fine and it is indeed tinygo that is to blame.

Hope this helps!

[deadprogram]

So far I have tried "blink an LED every time you write something to the UART, to make sure the program didn't crash." and have discovered that the program in fact DID crash.

Now I am going to try "running something else on the device that writes to the UART, to make really sure everything works fine and it is indeed tinygo that is to blame."

[deadprogram]

I was able to run the UART sample code provided with Zephyr so it is something in TinyGo that we are doing wrong or not doing, I suppose.

[deadprogram]

I was able to run using GDB and got the following output:

$ ./build/tgo gdb -target=reelboard ./src/examples/blinky1                                                             
GNU gdb (7.10-1ubuntu3+9) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-linux-gnu --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /tmp/tinygo626873308/main...done.
Remote debugging using :3333
0x00000000 in ?? ()
target halted due to debug-request, current mode: Thread 
xPSR: 0x61000000 pc: 0x00000424 msp: 0x20000ff0
Loading section .text, size 0x564 lma 0x0
Loading section .data, size 0x4 lma 0x564
Start address 0x0, load size 1384
Transfer rate: 1007 bytes/sec, 692 bytes/write.
Continuing.
WARNING! The target is already running. All changes GDB did to registers will be discarded! Waiting for target to halt.
^C
Program received signal SIGINT, Interrupt.
0x00000426 in (machine.UART).WriteByte (uart=<optimized out>, c=<optimized out>)
    at /home/ron/.gvm/pkgsets/go1.11/global/src/github.com/aykevl/tinygo/src/machine/machine_nrf.go:103
103             for nrf.UART0.EVENTS_TXDRDY == 0 {
(gdb) bt
#0  0x00000426 in (machine.UART).WriteByte (uart=<optimized out>, c=<optimized out>)
    at /home/ron/.gvm/pkgsets/go1.11/global/src/github.com/aykevl/tinygo/src/machine/machine_nrf.go:103
#1  runtime.putchar (c=<optimized out>)
    at /home/ron/.gvm/pkgsets/go1.11/global/src/github.com/aykevl/tinygo/src/runtime/runtime_nrf.go:50
#2  runtime.printstring (s=<optimized out>)
    at /home/ron/.gvm/pkgsets/go1.11/global/src/github.com/aykevl/tinygo/src/runtime/print.go:10
#3  0x0000051a in examples/blinky1.main ()
    at /home/ron/.gvm/pkgsets/go1.11/global/src/github.com/aykevl/tinygo/src/examples/blinky1/blinky1.go:20
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

[aykevl]

Strange. It looks like EVENTS_TXDRDY is never sent.
Do you maybe still get a single character (the first), or nothing at all?

[deadprogram]

Seems like nothing ever arrives, but hard to tell because by the time it connects the MCU has already gotten into a lockup state.

[aykevl]

Sleep must be working because blinking an LED works. You can try sleeping on startup before sending the first char, for example time.Sleep(10 * time.Second) so you have time to connect a serial device.

[aykevl]

This is even more reason to make stdout more configurable, to support ARM semihosting for cases like these.

[deadprogram]

Put in the delay, and was able to connect via serial before my LED blink, but did not receive any data.

[deadprogram]

This is the DTS file that descibes the board, BTW: https://github.com/zephyrproject-rtos/zephyr/blob/f8cbf7f92a8c68817f192e960e49be3c20f80e1f/boards/arm/reel_board/reel_board.dts

[deadprogram]

This is the info returned by the pyocd flasher, in case that is of any use:

Using runner: pyocd
Flashing Target Device
INFO:board:Target type is nrf52
INFO:root:DP IDR = 0x2ba01477
INFO:root:AP#0 IDR = 0x24770011
INFO:root:AP#1 IDR = 0x02880000
INFO:root:AP#0 ROM table #0 @ 0xe00ff000 (designer=244 part=008)
INFO:root:[0]<e000e000:SCS-M4 class=14 designer=43b part=00c>
INFO:root:[1]<e0001000:DWT class=14 designer=43b part=002>
INFO:root:[2]<e0002000:FPB class=14 designer=43b part=003>
INFO:root:[3]<e0000000:ITM class=14 designer=43b part=001>
INFO:root:[4]<e0040000:TPIU-M4 class=9 designer=43b part=9a1 devtype=11 archid=0000 devid=0:0:ca1>
INFO:root:[5]<e0041000:ETM-M4 class=9 designer=43b part=925 devtype=13 archid=0000 devid=0:0:0>
INFO:root:CPU core is Cortex-M4 r0p1
INFO:root:FPU present
INFO:root:4 hardware watchpoints
INFO:root:6 hardware breakpoints, 4 literal comparators
[====================] 100%
INFO:root:Programmed 48676 bytes (12 pages) at 11.20 kB/s
[100%] Built target flash

[aykevl]

Looks like flow control is missing. That may explain why you're not receiving anything.
However, that does not explain why sending chars does not work, the sender should be oblivious to whether the receiver is ready without flow control.

[deadprogram]

I thought hardware flow control was disabled by default, at least according to the datasheet. That said, you are certainly correct!

[deadprogram]

Acquired one of the nrf52840 Dev kits from Nordic and confirmed the same behavior.

[aykevl]

Yes, hardware flow control is disabled by default on the nef52840. But possibly not on the UART-USB chip (probably the debugger chip). You might want to check which pins are related to flow control and pull those high, just to be sure.
EDIT: nevermind, the nrf52840 should not hang at sending a byte when it has disabled flow control.

Now I think of it, maybe there is something wrong with gen-device-svd.py. There may be a bug in the addresses it creates, but how to check that without UART?

@glennrub do you maybe have an idea what's going on here? Is there anything special about the nrf52840 UART?

[deadprogram]

OK thanks to @jarz-nordic assist, the problem has been found.

@aykevl you were correct that is an error in the generated wrapper. Seems like extra padding is being added after a struct cluster.

For example, this extra padding should not be there:
https://gist.github.com/deadprogram/4f7bff995d5758340ce1da9fe03649c4#file-nrf52840-go-L503

[deadprogram]

Perhaps https://github.com/aykevl/tinygo/blob/master/tools/gen-device-svd.py#L328 is not setting the next address correctly?

[aykevl]

I'll have to look into it, maybe this evening. This code used to be relatively clean, but it's a mess at the moment so hard to debug.

[deadprogram]

Here is my proposed fix: #90

[deadprogram]

I've tested the regenerated files with nrf51, nrf52, and nrf52840 boards. All work as expected for UART and also still work for GPIO operations.

[aykevl]

I assume this bug has been fixed by #90. Please reopen if it isn't.