boards/arduino-mkr: feather-m0: sodaq-*: provide stdio over USB and setup automatic flash with bossa

[aabadie]

Contribution description

This PR provides stdio over USB to all Arduino MKR boards and setup the reset in bootloader mode like it's done with Arduino IDE.

In Arduino, the application resets in bootloader mode when the stdio is opened at 1200 baud.
In this PR, the hook function is implemented in board.c but the actual connection with cdc_acm_stdio is done in the cdc_acm_stdio module only when the RESET_IN_BOOTLOADER module is loaded. This might not be the cleanest solution but it works. Any better suggestion is welcome of course.

To be able to reset in bootloader, there are other tricks:

• open the serial at 1200 baud with stty
• force the bootloader mode after reset: this code was taken from @ynezz who commented about it in boards/feather-m0: initial support #7510. His code is here. I just readapted it for this PR.
• Adapted the build system in order to add a delay after preflash command (to let some time for the board to reset in bootloader mode)

I'm testing this PR with arduino-mkrfox1200 but it should work the same with other mkr boards. It's also easily adaptable to SODAQ and Feather-M0 boards.

Testing procedure

Just build/flash/term any application with an Arduino MKR board plugged via USB : the board is automatically flashed and stdio is printed (shell works as well).

Issues/PRs references

Based on (the awesome) #11085 to get the stdio over USB feature.

[keestux]

@aabadie This PR is currently just for arduino-mkr boards. Given the fact that all Sodaq boards (in RIOT) are fully compatible with Arduino Zero (and MKR) I foresee code duplication. What can do to support Sodaq boards (and perhaps others as well) in this PR?

[aabadie]

Given the fact that all Sodaq boards (in RIOT) are fully compatible with Arduino Zero (and MKR) I foresee code duplication

I know, the reset_in_bootloader function could be duplicated but this was also in my plans: provide a common directory for "sam0 with Arduino bootloader" boards. Of course, Feather-M0, SODAQ and maybe one Arduino (I think @dylad owns one) should also take advantage of this.

For the moment, this PR is just here as a POC of this feature so others can start test it and give feedback/review the code. It's just that I did that for MKR because there's already a common directory for those ones :)

[dylad]

@aabadie for reference, the board I have is the Seeeduino LoraWAN
(I plan to add it to RIOT one day...)

[aabadie]

Nice board @dylad :)

@keestux, I'll try to adapt this PR so that it's easy to reuse the reset_in_bootloader function in other similar boards.

[keestux]

@aabadie If I understand correctly it erases the first page after the bootloader and then does a hard reset. I must say, I'm not a fan of erasing to force entering the bootloader.

An alternative is to mimic the double tap to reset. After a double reset it enters the bootloader too. You only have to write a magic number (0x07738135) at the last uint32_t in RAM (i.e. 0x20007FFCul of a SAMD21).

[aabadie]

An alternative is to mimic the double tap to reset. After a double reset it enters the bootloader too. You only have to write a magic number (0x07738135) at the last uint32_t in RAM (i.e. 0x20007FFCul of a SAMD21).

Thanks! That looks much cleaner indeed. I'll give this a try.

[keestux]

With a quick hack on my sodaq-autonomo board I could repeatedly flash, with the reset_in_bootloader trick. Also using the "double tap" method to reset. In other words, this POC is working.

BTW, I used these make defines BOSSA_ARDUINO_PREFLASH=1 PREFLASH_DELAY=1 and tests/usbus_cdc_acm_stdio as a test app.

[aabadie]

@keestux, I implemented your reset in bootloader suggestion (which is in fact what is done by the Arduino bootloader when double tapping) and it works very well.
In the meantime, I added a way to simply reset the board, without going into bootloader mode. My goal was to address @fjmolinas concerns about automatic tests but unfortunately, after a reset the virtual com port is closed and reopened which breaks the test target. This is a similar problem we had with cc2538 based boards. Maybe there's a workaround ?

Now I'll try to factorize this feature and make use of it with Feather-M0/SODAQ boards.

[aabadie]

Now I'll try to factorize this feature and make use of it with Feather-M0/SODAQ boards.

Done. I added a common module for managing the "reset in bootloader" and "reset in application" actions. This module also provides the bossa configuration for flashing the boards.
This common module is used by all SODAQ boards (some factorization could be done here btw), Feather M0 and all Arduino MKR boards.

[dylad]

This common module is used by all SODAQ boards (some factorization could be done here btw), Feather M0 and all Arduino MKR boards.

Is there a chance to put arduino-zero on the list ?

[aabadie]

Is there a chance to put arduino-zero on the list ?

Arduino-zero doesn't need this since it comes with an on-board edbg debugger. In fact, the board is called genuino zero. I have another official Arduino version which also has the edbg debugger.

[dylad]

Arduino-zero doesn't need this since it comes with an on-board edbg debugger. In fact, the board is called genuino zero. I have another official Arduino version which also has the edbg debugger.

True but the story of arduino-zero is a bit complicate: arduino-zero could be use for arduino M0 Pro (with an embedded EDBG) but you have the small arduino-m0 which is basically a cheap little brother with the very same pinout, chip, etc. except there is no embedded debugger so BOSSA is mandatory.

[aabadie]

Tested this PR on feather-m0, sodaq-autonomo and sodaq-explorer. All worked. So I guess we are good once #11085 is merged and the cdc_acm_stdio hook (hack?) is validated :)

[aabadie]

Rebased, now that #11085 is merged!

[aabadie]

Note to myself: some board documentation have to be updated (feather-m0 and maybe some sodaq boards as well).

[fjmolinas]

You can squash @aabadie !

[fjmolinas]

Just to re-state what I said before, two things that will need to be improved in the future.

• Use of DEFAULT_MODULE for stdio, this does not properly work, but is currently the best solution for what is being attempted. I'll try to open an issue to state all the isues with DEFAULT_MODULE.

• FEATURES_REQUIRED += bootloader_arduino means adding +5k of code for every application even if not requiring usb or stdio. Would be nice to be able to disable it somehow from an application without having to go into application code. This is again not evident to do with out current build_system tools and layout.

But these are all build-system related concerns, the code itself works well for me. I'm going to count these issues as out of scope and move on with the review.

Otherwise, tested and works well, I have some issue locally with how much of a TERM_DELAY is needed, but seems to be a local issue for @aabadie its works straight away, and I have encountered similar issues in the past. Otherwise flash and reset are reliable unless the application crashes.

ACK!

[benpicco]

Maybe unrelated to this PR, but when a board has a proper VID:PID combination, how do I add that to the board?

I thought adding USB_VID=…, USB_PID=… to the board's Makefile.include should be enough, but that's not working (anymore?).

Directly adding CFLAGS += -DCONFIG_USB_VID=0x… would break the tests.

Now is this just an omission or am I missing something here?
#13652 should fix this.