nrf52840: Add serial bootloader

[microbuilder]

The nRF52840/PCA10056 support merged in via #573 currently only works with nrfjprog and a J-Link. A new serial bootloader needs to be implemented similar to the s132-based feather52 platform, but based on S140.

As an interim solution, this should ideally work with the USB CDC interface on the PCA10056 development board until an internal board is available (pending commercial module availability and final release of the nRF52840 from Nordic).

[arturo182]

The DK can also be flashed with OpenOCD via ST-Link or CMSIS-DAP ;)

[jerryneedell]

IS it still the case that AMPY will only work on the DK via the UART pins, and not via the USB port? This has been working OK for me, but on a few occasions it has resulted in a corrupted FS on the DK. Has anyone else seen this?
I posted this to the previous PR but here are the details:

lib
boot_out.txt
ubluepy_scan.py

jerryneedell@Ubuntu-Macmini:~/projects/feather52/examples$ ampy -d  1.5  -p /dev/ttyUSB0 put i2c_scan.py 
Traceback (most recent call last):
  File "/usr/local/bin/ampy", line 9, in <module>
    load_entry_point('adafruit-ampy==1.0.3', 'console_scripts', 'ampy')()
  File "/usr/local/lib/python3.5/dist-packages/click-6.7-py3.5.egg/click/core.py", line 722, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/lib/python3.5/dist-packages/click-6.7-py3.5.egg/click/core.py", line 697, in main
    rv = self.invoke(ctx)
  File "/usr/local/lib/python3.5/dist-packages/click-6.7-py3.5.egg/click/core.py", line 1066, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/lib/python3.5/dist-packages/click-6.7-py3.5.egg/click/core.py", line 895, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/lib/python3.5/dist-packages/click-6.7-py3.5.egg/click/core.py", line 535, in invoke
    return callback(*args, **kwargs)
  File "/usr/local/lib/python3.5/dist-packages/adafruit_ampy-1.0.3-py3.5.egg/ampy/cli.py", line 213, in put
  File "/usr/local/lib/python3.5/dist-packages/adafruit_ampy-1.0.3-py3.5.egg/ampy/files.py", line 146, in put
  File "/usr/local/lib/python3.5/dist-packages/adafruit_ampy-1.0.3-py3.5.egg/ampy/pyboard.py", line 263, in exec_
  File "/usr/local/lib/python3.5/dist-packages/adafruit_ampy-1.0.3-py3.5.egg/ampy/pyboard.py", line 255, in exec_raw
  File "/usr/local/lib/python3.5/dist-packages/adafruit_ampy-1.0.3-py3.5.egg/ampy/pyboard.py", line 225, in follow
ampy.pyboard.PyboardError: timeout waiting for second EOF reception
jerryneedell@Ubuntu-Macmini:~/projects/feather52/examples$ ampy -d  1.5  -p /dev/ttyUSB0 ls
lib
boot_out.txt
jerryneedell@Ubuntu-Macmini:~/projects/feather52/examples$ 

[microbuilder]

Traditionally the UART peripheral on the nRF5x chips has generally required HW flow control for reliable communications, which might be what's happening here. I have to do some further testing myself, and I don't know if the peripheral on the nRF52840 is more robust than previous UART blocks at the silicon level, but I've generally always had problems with them without CTS and RTS being used. Or it could simply be an issue with the USB stack and pass through running through the on board debugger chip that also provides the J-Link interface.

A purely USB based solution running natively on the nRF52840 would solve this though since it bypasses the UART HW block entirely, though I think we should have a HW UART backup option as well and not assume native USB will always be available.

[arturo182]

I have been using UART on the nRF family without HW flow control for a long time and never had any problems. I believe the issue here is that the UART is passed through the JLink chip which seems to corrupt the data coming into the nRF.

[jerryneedell]

@microbuilder Thanks - I do have an "FTDI Friend" that support HW Flow control. I will try connecting that instead of the cable I am using now that only has TX/RX and see if that makes any difference.

[arturo182]

I have been using a external USB to UART board with only RX/TX and had no problems with ampy.

[jerryneedell]

@arturo182 good to know. I'll keep track of the issues I have with ampy and see if I can find a reproducible issue.

[microbuilder]

@arturo182 They redid the entire UART block migrating from the nRF51 (which didn't work reliably without flow control and had a tiny internal FIFO) to the nRF52, which improved things, but we had to fix issues in this fork to get paste mode working 100% reliably, for example. It's a combination of firmware and proper use of the HW, but I've been bitten enough by the UART blocks I don't trust them. :P The problem here is almost certainly the chip with the J-Link firmware, though, but the more people that abuse the code, the more likely issues are to come to the surface and get fixed, so thanks for the help poking at this stuff.

[microbuilder]

Purely for convenience sake, the UART pinout on the PCA10056 is as follows:

Source: http://infocenter.nordicsemi.com/pdf/nRF52840_PDK_User_Guide_v1.0.pdf

[microbuilder]

See #623