forgot to remove the pwm feature for the board (as I did not define any configuration for this). Now Murdock should hopefully be happy...

What version of OpenOCD are you using? I'm getting the following error:

Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
adapter speed: 10000 kHz
cortex_m reset_config sysresetreq
Info : CMSIS-DAP: SWD  Supported
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : CMSIS-DAP: FW Version = 1.10
Info : SWCLK/TCK = 0 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : reduce speed request: 10000kHz to 5000kHz maximum
Info : clock speed 10000 kHz
Info : SWD DPIDR 0x2ba01477
Info : nrf52.cpu: hardware has 6 breakpoints, 4 watchpoints
    TargetName         Type       Endian TapName            State       
--  ------------------ ---------- ------ ------------------ ------------
 0* nrf52.cpu          cortex_m   little nrf52.cpu          halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x00000470 msp: 0x20000200
invalid subcommand "write_image erase /home/jcarrano/source/masterRIOT/examples/hello-world/bin/reel/hello-world.elf 0"
in procedure 'flash'

Also, if someone else wants to try this, be sure to move the switch out of the "off" position, seems like they cheaped out and didn't include a power multiplexer.

all comments addressed.

Anyone care to ACK so I can squash?

After upgrading to OpenOCD 0.10.0+dev-00706-g4db695c66 (from the AUR) I was able to flash.

I ran ./dist/tools/compile_and_test_for_board/compile_and_test_for_board.py . reel.

Failures during test:

• [tests/fmt_print](tests/fmt_print/test.failed)
• [tests/gnrc_ipv6_ext](tests/gnrc_ipv6_ext/test.failed)
• [tests/gnrc_netif](tests/gnrc_netif/test.failed)
• [tests/gnrc_rpl_srh](tests/gnrc_rpl_srh/test.failed)
• [tests/gnrc_sixlowpan](tests/gnrc_sixlowpan/test.failed)
• [tests/od](tests/od/test.failed)
• [tests/xtimer_now64_continuity](tests/xtimer_now64_continuity/test.failed)

All these failures originate in the fmt module, specifically, the print function fails, because write fails (but not fwrite!). This code will not output anything (except the RIOT welcome banner):

#include <unistd.h>

int main(void)
{
    write(1, "123456789\n", 10);

    return 0;
}

I don't have the reel board here right now, but this seems rather unrelated to this PR to me?! Tried the tests on the nrf52dk (the closest board I have available right now), and they work fine. Also the example code posted above works as expected. And as the nrf52dk is using >95% identical code to the nrf52840, it seems odd to me that the reel board fails, especially considering that the board configuration has no obvious impact in the workings of the stdlib-wrappers...

Will give this another try tomorrow when I'm back in the office.

Just tested on the nrf52840dk, and I get the same faulty behavior running 'tests/fmt_print. So the problem is indeed related to the nrf52840CPU port, and independent of thereel` board. Very interesting though :-)

Will debug this today to see whats causing this...

As suspected, the issue at hand was unrelated to this PR (effecting all nrf52840-based boards). It is fixed with #11170.

So this PR should be ready to go then?

@jcarrano any luck testing this PR now with #11170 merged? Can I squash?

I'm out of office until Tuesday. Squash, there is no point in keeping it unsquashed.

squashed

Sounds good, all green, so go.

@haukepetersen Are you interested in the eInk driver support? I started playing around with an epaper display from gooddisplay.
It has different commands, but It probably makes sense to also have some kind of abstraction for epaper there. Something like SAUL? So, if you are interested, we could combine our efforts there :)

@Citrullin yes, that would be very interesting. I personally won't however have much time to spend on this, but maybe there is others in the community that would like to collaborate I am sure.