Add port for Analog Devices MAX32 MCUs

[BrentK-ADI]

Describe the PR
Add support for the Analog Devices MCUs MAX32650/1/2, MAX32665/6, MAX32690 and MAX78002.

Additional context
The USB IP for these devices is identical amongst the part families and uses a variation of the Mentor IP core. dcd_musb.c was used as the baseline implementation, modified for the part specific FIFO, register access and PHY control.

Supported Boards:

• MAX32650EVKIT
• MAX32650FTHR
• MAX32651EVKIT
• MAX32666EVKIT
• MAX32666FTHR
• MAX32690EVKIT
• AD-APARD32690-SL
• MAX78002EVKIT

[hathach]

thank you for your PR, I think we should update the dcd_musb.c to support max32 instead of duplicating an new driver. Since that make maintanence easier in the future. I can help with that, give me a bit of time, I will try to find an dev board to test this out.

PS: digikey backorder is 09/20, this probably take a while.

[BrentK-ADI]

Thanks @hathach. As part of that potential merging of the existing dcd_msub.c with my updates, should probably also look at the sunxi version as well. The scope of modifications for that were similar to mine.

Unfortunate about the back order. Once you get hardware reach out if you have any questions or issues getting up and running.

[hathach]

Thanks @hathach. As part of that potential merging of the existing dcd_msub.c with my updates, should probably also look at the sunxi version as well. The scope of modifications for that were similar to mine.

Unfortunate about the back order. Once you get hardware reach out if you have any questions or issues getting up and running.

yeah, sunxi uses the same mentor usb, but it is more complicated since it is actually arm9 processor. I want to do that also but couldn't mannage the time.

For dev board, this one look reasonable https://www.digikey.com/en/products/detail/analog-devices-inc-maxim-integrated/MAX32666FTHR/12727215 (lead time is 09/02), will let you know once I got the hardware.

[BrentK-ADI]

For dev board, this one look reasonable https://www.digikey.com/en/products/detail/analog-devices-inc-maxim-integrated/MAX32666FTHR/12727215 (lead time is 09/02), will let you know once I got the hardware.

Yes, that board will work out well for testing. The MAX32650FTHR is also a good choice for a small form factor board, but same 9/20 lead time at Digikey.

[hathach]

Feather 666 is a bigger chip with dual core but cost less than 650 and also available earlier so it is better choice I guess.

[hathach]

Updated: requested by @tannewt, I did a bit more search and found mouser having these in stocks, just ordered max32650,666,690 boards (sponsored by Adafruit). It will probaly take a week or so for it to get delivery. Meanwhile @BrentK-ADI If possible, you can try to merge the dcd_max32 to dcd_musb, probably create an header musb_max32.h and abstract/put max32 specific function there. you could check out dwc2 for reference. We will try to get this merge as soon as I could.

[BrentK-ADI]

@hathach , I'll start digging into that merge. Hopefully can get something together by the end of the week.

[BrentK-ADI]

@hathach, I took a shot at combining the existing DCD MUSB with the new MAX32. Things were a little trickier than the dwc2 example, for a couple reasons:

• The EP registers are the same packing/data types, but accessed differently between TI and MAX32. TI has a contiguous memory map where each EP register set follows the previous. MAX32 uses a shared memory space and an index to determine which EP is being accessed
• The FIFOs on the TI parts need to be configured, where as the MAX32 has dedicated memory for each EP.

With that said, as well as a couple other hooks for interrupt handling, I think the implementation is fairly clean and easy to follow, and retained all of the original dcd_musb.c logic and register handling. Let me know your thoughts.

I happened to have a EK-TM4C123GXL board hanging around so was able to at least re-run the example projects on that board to verify functionality was consistent with the updates.

[hathach]

@BrentK-ADI perfect thank you, my order from Mouser already shipped, it will probably delivery in a few days. Let hope we could get this merged as soon as we could.

[BrentK-ADI]

For some reason my codespell didn't catch that error when I ran pre-commit. I'll hold off fixing it if there are other updates needed for this merge to avoid a frivolous entry in the commit log.

[hathach]

For some reason my codespell didn't catch that error when I ran pre-commit. I'll hold off fixing it if there are other updates needed for this merge to avoid a frivolous entry in the commit log.

no problems, my order is in custom clearance, it should be delivered in a couple of days.

[hathach]

I got the feather dev boards, will start to test/review and make changes if needed to merge this PR asap. If you have an pending update, please push it if possible to prevent conflict/merge thanks.

[hathach]

I have bring this PR updated to master, add max32 to ci build and fixes some warning when compiling with cmsis header v3 (in the mcu/max32). Will do more extensive test with actual hw tomorrow.

[hathach]

Tested with feather maax32866, it works as a charm, passed my local hil test with both TI tm4c and max32666, I am doing a bit of more refactor, but probably wont change the driver behavior. We probably merge this real soon (hopefully). Note: since I have both max32650 and 666, I will add one to the hil pool as well to get it tested with the ci.

[BrentK-ADI]

Glad things worked smoothly. Thanks for putting the time into this!

[hathach]

@BrentK-ADI Everything went smoothly, I push more refactor to generalize register interfacee. I also tried to include max32650 to my hardware-in-the-loop pool #2194 which is running on a Raspberry Pi 5 (flashing hardware and run test script to verify usb function). Therefore I tried to compile openocd (analog fork) https://github.com/analogdevicesinc/openocd but got following error on my Linux x86.

/usr/bin/ld: src/.libs/libopenocd.a(adi_v6_jtag.o):/home/hathach/code/openocd_analog/src/target/adi_v6_jtag.c:181: multiple definition of dap_cmd_pool'; src/.libs/libopenocd.a(adi_v5_jtag.o):/home/hathach/code/openocd_analog/src/target/adi_v5_jtag.c:151: first defined here
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:3111: src/openocd] Error 1
make[2]: Leaving directory '/home/hathach/code/openocd_analog'
make[1]: *** [Makefile:4468: all-recursive] Error 1
make[1]: Leaving directory '/home/hathach/code/openocd_analog'
make: *** [Makefile:2100: all] Error 2

here is my configure (mostly default)

./configure --disable-werro
OpenOCD configuration summary
--------------------------------------------------
MPSSE mode of FTDI based devices        yes (auto)
ST-Link Programmer                      yes (auto)
Analog Devices ICE-1000                 yes (auto)
Analog Devices ICE-2000                 yes (auto)
Analog Devices Debug Agent              yes (auto)
TI ICDI JTAG Programmer                 yes (auto)
Keil ULINK JTAG Programmer              yes (auto)
Altera USB-Blaster II Compatible        yes (auto)
Bitbang mode of FT232R based devices    yes (auto)
Versaloon-Link JTAG Programmer          yes (auto)
TI XDS110 Debug Probe                   yes (auto)
OSBDM (JTAG only) Programmer            yes (auto)
eStick/opendous JTAG Programmer         yes (auto)
Andes JTAG Programmer                   yes (auto)
USBProg JTAG Programmer                 no
Raisonance RLink JTAG Programmer        no
Olimex ARM-JTAG-EW Programmer           no
CMSIS-DAP Compliant Debugger            yes (auto)
Cypress KitProg Programmer              yes (auto)
Altera USB-Blaster Compatible           no
ASIX Presto Adapter                     no
OpenJTAG Adapter                        no
Linux GPIO bitbang through libgpiod     no
SEGGER J-Link Programmer                yes (auto)

Maybe I miss something, would you mind poiting me to instruction to compile ADI's openocd for to run on a RPI 5. Thank you.

[BrentK-ADI]

@hathach As far as I know that is the right repo. I believe it should be the release branch vs adi-main or master. I was able to build that branch with the normal OpenOCD instructions:

To build OpenOCD, use the following sequence of commands:

  ./bootstrap (when building from the git repository)
  ./configure [options]
  make
  sudo make install

If that's still causing you problems, I'll ping the group that maintains the tools for these MCUs on Monday and get more guidance.

[hathach]

@BrentK-ADI thank you, I change the branch to release and it compiles perfectly. I was on the default adi-main previousls. Shouldd have tried that first, not too familliar with Analog tool (have been using jlink so far for developing) :)

[hathach]

I am able to add feather max32666 to the hil pool. Somehow, someway, I fried my feather max32650 while trying to flash with openocd, no 3v3 measured,power with lipo battery does not work as well (it has been doing just fine with jlink). Luckily I still have an extra max32690 ekit (though it is a bit trunky).

[hathach]

thank you very much for your awesome work. PR works out the box with max32650/666/690 at first try. I have done quite a bit of refactoring mostly with dcd musb (hcd isn't touched yet) with

• declare general musb register
• add musb configuraation option MUSB_CFG_SHARED_FIFO/MUSB_CFG_DYNAMIC_FIFO which is the main difference between adi and ti implementation
• indexed tx/rx register to make the code look cleaner
• implement dcd_edpt_iso_alloc()/activate() for TI port, which makes it simpler without fifo size allocation management.
• enable double buffer for ISO

most bulkd/interrupt examples work well. ISO though isn't working too well audio_test does not work as expected, video_capture (with CFG_TUD_VIDEO_STREAMING_BULK=0 for using ISO) only work as proof of concept (kind of laggy), which shouldn't be the caase with max32 with huge fifo depth. But it is probably our bug. We will fix this later with following up PR since this is already large enough.

[BrentK-ADI]

Thanks so much for pushing this through so fast!

[hathach]

No problem, I am the one to say thank. Thanks again for your contribution on the PR. There is still work for ISO endpoint, but we can do that later