perfect thank you, please give me a bit of time to review and test this. I have a question, Since these are similar, should we merge them together as max32/analog ports, that would reduce the duplication. I plan to do that with tinyusb as well when having time. But if you think this is ok, we can leave this for now.

Merging the devices together also crossed my mind when doing the port. There are just enough nuances between the underlying API calls and operation between parts that I worry having some pre-processor conditional blocks for the variations will make things unreadable and hard to follow. Diff'ing the board.c and board_flash.c files between parts will give you an idea of what I mean by nuances.

I am open to any suggestions you have to combine things together. Let me know, as well as if you run into any issues/questions, etc.

thanks, I will try to make some update and testing, since PR is rather large, this may take a bit of time.

hi @BrentK-ADI thank you for the great PR, the code work super well, I have tested the blinky app and update-tinyuf2 (self_update), both are working well on my feather max32666 and max32690evkit. Furthermore, I have merged all the maxim mcu into common ports/maxim in this branch https://github.com/adafruit/tinyuf2/tree/add-max32-support (since it does lots of rename and delete), but I have only done that with cmake, which I found much easier to manage and is primarily using. To build you need

cd ports/maxim
mkdir build
cd build
cmake -DBOARD=max32666fthr ..
make  <--- this will build tinyuf2 + all apps: blinky, update-tinyuf2
cmake --build . --target tinyuf2-jlink  <--- flash with jlink
cmake --build . --target tinyuf2-openocd <--- flash with openocd (check family_support.cmake for its path requirement)

Please try it out to see if this makes sense to you. We can have an wrapper for make to run cmake as back-end (I am migrating to cmake), though let me know if you still like to have make as an indepedent build-system, we can get that done as well since you already done most of the works.

PS: also rename dependency analog/max32 to analog/msdk.

@hathach , thanks for the review and feedback. Got a little busy with a couple things, hopefully can get back to this this week.

@hathach , thanks for the review and feedback. Got a little busy with a couple things, hopefully can get back to this this week.

no problems at all, we are all busy.

@hathach, Had a chance to run through all this. Thanks for putting all this extra work in!

The cmake build system is fine with me. I was able to use the tools that come with our MSDK installer, no need to have an independent Make wrapper. I like how you were able to combine the different MCUs into a single port, that all looks good.

One issue:
Not sure the root cause of this, whether it be the cmake optimization rules, or something else, but the bootloader executable ends up linking to 45kB on my old toolchain (GCC 10.3.1), exceeding the 32kB set for FLASH_BOOT_SIZE. I didn't have this problem in my original commits, so not sure what changed. Either way, bumping FLASH_BOOT_SIZE to 64kB should be fine, no need to investigate further.

Let me know if you want me to PR the flash size fix into the add-max32-support branch, of if you just want to handle it.

Thanks!

@hathach, Had a chance to run through all this. Thanks for putting all this extra work in!

The cmake build system is fine with me. I was able to use the tools that come with our MSDK installer, no need to have an independent Make wrapper. I like how you were able to combine the different MCUs into a single port, that all looks good.

Great, I am glad you like the idea, I also plan to do only cmake for future ports.

One issue: Not sure the root cause of this, whether it be the cmake optimization rules, or something else, but the bootloader executable ends up linking to 45kB on my old toolchain (GCC 10.3.1), exceeding the 32kB set for FLASH_BOOT_SIZE. I didn't have this problem in my original commits, so not sure what changed. Either way, bumping FLASH_BOOT_SIZE to 64kB should be fine, no need to investigate further.
Let me know if you want me to PR the flash size fix into the add-max32-support branch, of if you just want to handle it.

Thanks!

Ah, you need to pass -DCMAKE_BUILD_TYPE=MinSizeRel in the connfigure it to compile with -Os and/or flto, please try again to see if it works out. I got around 20KB for max32666

cmake -DBOARD=max32666fthr -DCMAKE_BUILD_TYPE=MinSizeRel ..

Memory region         Used Size  Region Size  %age Used
            SPIX:           0 B       128 MB      0.00%
           FLASH:       19732 B        32 KB     60.22%
            SRAM:       16624 B     573436 B      2.90%
            SPID:           0 B       512 MB      0.00%
   text	   data	    bss	    dec	    hex	filename
  19730	      0	  15464	  35194	   897a	/home/hathach/code/adafruit/tinyuf2/cmake-build-max32666fthr/ports/maxim/tinyuf2.elf

PS: I have made MinSizeRel as default build type, you can try again without the need to specify it with -D

also update README for cmake build instruction and removed make-related files. Please pull and try again (it is rebased to master, you may need a clean checkout). Feel free push any update to readme or any files. Also I am only able to test with max32666fthr and max32690ekit (I bricked the maax32650 when mistakenig flashing 32666 firmware on it), so please test with other board in the maxim. If everything is good, we can merge this

also update README for cmake build instruction and removed make-related files. Please pull and try again (it is rebased to master, you may need a clean checkout). Feel free push any update to readme or any files. Also I am only able to test with max32666fthr and max32690ekit (I bricked the maax32650 when mistakenig flashing 32666 firmware on it), so please test with other board in the maxim. If everything is good, we can merge this

I made an update to family_support.cmake for OpenOCD flashing:

• $ENV{MAXIM_PATH} was getting mangled when running the flashing operation on Windows. I updated to use the file(TO_CMAKE_PATH feature to normalize the path for use. This got everything working OK.
• The MAXIM_PATH if block called out the ENV version by accident. That was corrected.
• Moved the CMake MAXIM_PATH to the first check. It seems if someone wanted to pass it on the command line, it should take precedence over the ENV.

Some README file updates were also done to reflect the updated build system. I had @marcoramirezcastro take a look since he did the documentation originally for me.

I tested on all the boards supported by the port. I'm good with it to be merged if you are.