@htamas: Thanks for the detailed report! Here are my immediate thoughts and reponses to your list of issues: (1) We didn't want to go wild with jumpered headers, so we put a number of header positions on the development board that are already shorted across with a trace on the board. The J8 and J9 headers feed the board from the regulated power supplies. Most users will just want to leave them alone and power the board in the default manner. For people who want to do something like supply a clean voltage from off-board or connect an ammeter to measure the project's power draw, the trace between the headers can be cut with a knife and a header installed, using a jumper to get back to the default configuration. If you do not cut the traces across J8 and J9, then installing a header there will only serve to prevent you from reaching the trace to cut it should you need to do so in the future. (Edited: I do not have a copy of the Nucleo hat board in question and answered based on another development board. My corrected response is in the answer to the next post, but the short answer is "sorry, we should have sent two more shunts to you.") (2) I will see if we can start providing two USB cables for the projects we ship with the Nucleo boards. One cable allows the Nucleo board memory to be mounted onto the host computer as a filesystem. It is possible to do everything without that cable, but I think our Makefiles are assuming that cable is installed. I rarely have issues with USB cables except that sometimes I find that a manufacturer has supplied a charging-only cable that has no data connections. (3) The independent vs. dependent hold violations is a lengthy issue to discuss, so I'll make a separate post about that (I have made some posts about it before, but searching Slack is a pain, so I'll do it again here and maybe it can be pinned for easier reference). (4) I would need to ask Jeff DiCorpo whether the lack of "pass" means that the boards failed or that they weren't tested. I think it's the latter---we test enough to ensure that we're giving you some known-good chips, and won't ship you a known-bad chip. There are various reasons that a chip that passes once might not pass later, due to differences in test conditions. I would hope that that would be rare, but I could be wrong. (5) Thanks for the pointer to the pre-built RISC-V compiler. I have had some difficulty myself getting the toolchain to compile and install correctly. It can be a royal pain. (6) I also use symlinks for the configuration definition files, having one file per chip (and assuming it doesn't change over time); so I'll make a file name like

gpio_config_def_D3_6.py

, and

gpio_config_def.py

is then a symbolic link to the configuration for whichever chip I've got on the development board. This method ought to be described and encouraged in the documentation.