Flash using tx/rx pins

[gerdes1723]

I'm trying to use an itsybitsy m4 express as part of an embedded system, where I would occasionally want to perform firmware updates from a connected raspberry pi. I've been trying to upload arduino code from a raspberry pi using arduino-cli, but that only works over usb. In an attempt to simplify my testing, I've also tried uploading from the arduino ide using a windows pc. That also works only using usb. However a simple test of serial prints shows the uart connection over the tx/rx pins is working as expected, serial prints show up in the console.

I suspect this could be related to the bootloader on the itsybitsy, does anyone know if it supports code uploads through the uart, or must it be on usb? I've tried putting the itsybitsy into programming mode by double clicking the button both before and during the upload process, and nothing seems to work. Searching online I've found a handful of examples of code upload using the pins, however never for this particular microcontroller.

[mikeysklar]

Is there a reason you do not want to use USB for upload?

There is another option which is to use the JTAG pins on the ItsyBitsy M4. You will use the SWDIO and SWCLK pins. Since you are using a Raspberry Pi that can setup as JTAG programmer using OpenOCD.

D614E34F-253F-4C8D-9A77-3038F17B7F39.jpeg (216.5 KiB) Viewed 150 times

[gerdes1723]

The main reason I want to avoid using the usb is because I have a space-constrained package that this system needs to be installed in. So the ribbon cable between the usb ports on the pi and the arduino ends up getting a little awkward, when it could be possible to set this up as a hat which sits on top of the pi.

The approach you shared is interesting, although after reading about it I'm wondering if this will work for uploading new code, or just for uploading a new bootloader. I only have a limited understanding of how this works, but it seems like maybe there's a way to set up arduino-cli to push new code using JTAG/openOCD through this bit-banging approach. I'll try this out and see if I can get it to work properly.

Meanwhile, I've been digging around trying to find the right search terms and locations, and I think I'm making some progress in my search: https://github.com/microsoft/uf2-samdx1/issues/42

It appears it's related to the configuration of the bootloader UART, and someone else has managed to accomplish what I'm trying to do in the past. So in parallel I'll try this approach and see if it works too.

[gerdes1723]

I've been messing around with this for a while and I keep getting strange errors. Most times when I send bossac --debug --port=COM7 --info I get the following: Send auto-baud, Set binary mode, No device found on COM7. But, maybe one time out of 4 I get version()=uart serial, Connected at 115200 baud, SAM-BA operation failed. And sometimes I get version()=rt serial, or version()=serial. So there seems to be a weird issue with serial comms not syncing properly.

Here's the changes I made to the bootloader in an attempt to get this working:
in inc/uf2.h I have #define USE_UART 1

in boards/itsybitsy_m4/board_config.h I have left things alone, since it appears to be using sercom 3.0 and 3.1 already, which should be the tx/rx pins.

Anybody have a guess as to what's going on here?

[gerdes1723]

Further updates: this strange behavior seems to be related to the board running something that prints on the Serial1 pins. If I upload a sketch that does nothing, it always reports no device found on COM7, and if I upload a sketch that rapidly prints on Serial1, I get a few readWord(addr=0x.......)=0x...... type outputs, but then bossac reports Device unsupported. So all this only happens when the board isn't in bootloader mode. If the board is in bootloader mode, bossac always fails to communicate with it.

I wonder is it necessary to reconfigure the SERCOM or pads to enable flashing over the pins? Maybe it conflicts with the serial port in some way.

[mikeysklar]

I see in the open issues of the Adafruit bootloader github repo that someone has created a custom fork that helps with the UART change.

https://github.com/adafruit/uf2-samdx1/issues/22

have a look at my fork here https://github.com/dominicjprice/uf2-samdx1 and the projecthoop branch. The bootloader already contained the code for updating over UART, it just needed compiling in (and another method being left out due to size constraints).

Another M4 user is struggling with the UART1 change on a metro AirLift.

https://github.com/adafruit/uf2-samdx1/issues/178

Both have some discussion that be helpful.

I would still encourage the JTAG setup with a custom board which buys you full single step hardware debug and the ability to program a board from bare metal. Not just bootloader (which would not longer be necessary), but running Arduino or CircuitPython code as well.

Another option would be to use a really small USB converter like this micro-B OTG if you were using a Pi Zero.

https://www.adafruit.com/product/2910

[gerdes1723]

First off thanks very much mikeyskylar for your help with this. I've been messing with it for quite a while now and finally making some good progress. I dug into the firmware, in particular the board_config.h file and discovered some weirdness there. In an attempt to simplify things, I adjusted that file to point at SERCOM1 instead of SERCOM3, as follows:

#ifndef BOARD_CONFIG_H
#define BOARD_CONFIG_H

#define CRYSTALLESS 1

#define VENDOR_NAME "Adafruit Industries"
#define PRODUCT_NAME "ItsyBitsy M4 Express"
#define VOLUME_LABEL "ITSYM4BOOT"
#define INDEX_URL "http://adafru.it/"
#define BOARD_ID "SAMD51G19A-Itsy-v0"

#define USB_VID 0x239A
#define USB_PID 0x002B

#define LED_PIN PIN_PA22

#define BOARD_RGBLED_CLOCK_PIN PIN_PB02
#define BOARD_RGBLED_DATA_PIN PIN_PB03

#define BOOT_USART_MODULE SERCOM1
#define BOOT_USART_MASK APBAMASK
#define BOOT_USART_BUS_CLOCK_INDEX MCLK_APBAMASK_SERCOM1
#define BOOT_USART_PAD_SETTINGS UART_RX_PAD1_TX_PAD0
#define BOOT_USART_PAD3 PINMUX_UNUSED
#define BOOT_USART_PAD2 PINMUX_UNUSED
#define BOOT_USART_PAD1 PINMUX_PA17C_SERCOM1_PAD1
#define BOOT_USART_PAD0 PINMUX_PA16C_SERCOM1_PAD0
#define BOOT_GCLK_ID_CORE SERCOM1_GCLK_ID_CORE
#define BOOT_GCLK_ID_SLOW SERCOM1_GCLK_ID_SLOW

#endif

I dug up the values for the BOOT_USART_PAD0/1 by looking at the datasheet here: https://ww1.microchip.com/downloads/aem ... 001507.pdf

And with these settings, plus the update to USE_UART 1 in uf2.h, I finally get a response when I send the bossac debug command. I have a feeling they have some settings wrong in the board_config.h file for the itsybitsy_m4. Here's that board_config.h:
#ifndef BOARD_CONFIG_H
#define BOARD_CONFIG_H

#define CRYSTALLESS 1

#define VENDOR_NAME "Adafruit Industries"
#define PRODUCT_NAME "ItsyBitsy M4 Express"
#define VOLUME_LABEL "ITSYM4BOOT"
#define INDEX_URL "http://adafru.it/"
#define BOARD_ID "SAMD51G19A-Itsy-v0"

#define USB_VID 0x239A
#define USB_PID 0x002B

#define LED_PIN PIN_PA22

#define BOARD_RGBLED_CLOCK_PIN PIN_PB02
#define BOARD_RGBLED_DATA_PIN PIN_PB03

#define BOOT_USART_MODULE SERCOM3
#define BOOT_USART_MASK APBAMASK
#define BOOT_USART_BUS_CLOCK_INDEX MCLK_APBBMASK_SERCOM3
#define BOOT_USART_PAD_SETTINGS UART_RX_PAD1_TX_PAD0
#define BOOT_USART_PAD3 PINMUX_UNUSED
#define BOOT_USART_PAD2 PINMUX_UNUSED
#define BOOT_USART_PAD1 PINMUX_PA22C_SERCOM3_PAD0
#define BOOT_USART_PAD0 PINMUX_PA23C_SERCOM3_PAD1
#define BOOT_GCLK_ID_CORE SERCOM3_GCLK_ID_CORE
#define BOOT_GCLK_ID_SLOW SERCOM3_GCLK_ID_SLOW

#endif

It looks like pad 0 and pad 1 are getting mixed up in those definitions. Maybe I can prove this theory later but for now other tasks demand my time at work. Meanwhile, I'll continue fiddling with your suggested approach of openOCD on the pi, as I do like the lower level debug control, but that's a bigger learning curve for me since it doesn't seem to be all that well documented if things go wrong.

Hopefully someone else can benefit from this without spending as much time as I did digging into it!

[gerdes1723]

One last update, the approach in my last post breaks serial comms on Serial1, since I guess it's now dedicating that UART to boot and code flashing. I did a similar adjustment to enable things on SERCOM3, and my suspicion was correct, there are bugs in the board_config.h for the itsybitsy_m4. Here's what I used that works properly for flashing code, and also doesn't break serial comms on the tx/rx pins (serial1):

#ifndef BOARD_CONFIG_H
#define BOARD_CONFIG_H

#define CRYSTALLESS 1

#define VENDOR_NAME "Adafruit Industries"
#define PRODUCT_NAME "ItsyBitsy M4 Express"
#define VOLUME_LABEL "ITSYM4BOOT"
#define INDEX_URL "http://adafru.it/"
#define BOARD_ID "SAMD51G19A-Itsy-v0"

#define USB_VID 0x239A
#define USB_PID 0x002B

#define LED_PIN PIN_PA22

#define BOARD_RGBLED_CLOCK_PIN PIN_PB02
#define BOARD_RGBLED_DATA_PIN PIN_PB03

#define BOOT_USART_MODULE SERCOM3
#define BOOT_USART_MASK APBBMASK
#define BOOT_USART_BUS_CLOCK_INDEX MCLK_APBBMASK_SERCOM3
#define BOOT_USART_PAD_SETTINGS UART_RX_PAD1_TX_PAD0
#define BOOT_USART_PAD3 PINMUX_UNUSED
#define BOOT_USART_PAD2 PINMUX_UNUSED
#define BOOT_USART_PAD1 PINMUX_PA23C_SERCOM3_PAD1
#define BOOT_USART_PAD0 PINMUX_PA22C_SERCOM3_PAD0
#define BOOT_GCLK_ID_CORE SERCOM3_GCLK_ID_CORE
#define BOOT_GCLK_ID_SLOW SERCOM3_GCLK_ID_SLOW

#endif