Refactor max32630fthr port example build

[head5man]

Refactor the overall make experience

Make sure the make targets and generation scripts work on all levels.
Remove unnecessary dependencies (low hanging fruit).
Use .mk extension for template and includes and Makefile only for folder make files (main).
Extract most of the dependency and path definitions from project Makefile into separate Dependencies.mk.
Keep git changes clean by ignoring volatile example folders.

[head5man]

Development is ongoing:
https://github.com/head5man/btstack/tree/max32630-fthr-improve-script-reusability

Is there a guideline of including the required tools and scripts from the compatible SDK as part of the port files?

In the current state of the bstack/port/max32630-fthr establishing the board build environment is quite tricky due to the latest sdk not supporting the max32630.

Currently using external repository to develop and maintain a build environment consisting of devcontainer and tools required for build a.k.a. $(MAXIM_PATH) extracted from windows installation of ARMCortexToolchain.exe.
https://github.com/head5man/btstack-GCC-devcontainer-max3263X.git

ping: @mringwal

[mringwal]

Hi @head5man

Thanks for looking into the max32630fthr port. I haven't been aware that the 32630 isn't supported by the latest Maxim SDK anymore. In that case, I guess the best option would be if the port could be compiled with a regular ARM Toolchain.

As for the files in MAXIM_PATH: one option would be to mirror them in this port (similar to stm32-f4discovery-cc2564 and other ports), or, to download them as part of the build from a fixed location (e.g. a github repository), as they are basically unsupported anyway. If you want to

--

When compiling your PR on macOS with ARM Toolchain 13.1.1, I get this warning/error:

Source/nvic_table.c: In function 'NVIC_SetRAM':
Source/nvic_table.c:77:5: warning: 'memcpy' forming offset [4, 271] is out of the bounds [0, 4] of object '__isr_vector' with type 'uint32_t' {aka 'long unsigned int'} [-Warray-bounds=]
   77 |     memcpy(&ramVectorTable, &__isr_vector, sizeof(ramVectorTable));
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Source/nvic_table.c:75:21: note: '__isr_vector' declared here
   75 |     extern uint32_t __isr_vector;
      |                     ^~~~~~~~~~~~

Is this a problem?

Btw. all development happens on the develop branch as we keep the master branch as a release branch.

[head5man]

Hi @head5man

Thanks for looking into the max32630fthr port. I haven't been aware that the 32630 isn't supported by the latest Maxim SDK anymore. In that case, I guess the best option would be if the port could be compiled with a regular ARM Toolchain.

As for the files in MAXIM_PATH: one option would be to mirror them in this port (similar to stm32-f4discovery-cc2564 and other ports), or, to download them as part of the build from a fixed location (e.g. a github repository), as they are basically unsupported anyway. If you want to

--

When compiling your PR on macOS with ARM Toolchain 13.1.1, I get this warning/error:

Source/nvic_table.c: In function 'NVIC_SetRAM':
Source/nvic_table.c:77:5: warning: 'memcpy' forming offset [4, 271] is out of the bounds [0, 4] of object '__isr_vector' with type 'uint32_t' {aka 'long unsigned int'} [-Warray-bounds=]
   77 |     memcpy(&ramVectorTable, &__isr_vector, sizeof(ramVectorTable));
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Source/nvic_table.c:75:21: note: '__isr_vector' declared here
   75 |     extern uint32_t __isr_vector;
      |                     ^~~~~~~~~~~~

Is this a problem?

Btw. all development happens on the develop branch as we keep the master branch as a release branch.

Hi @mringwal

Thanks for coming back to me with the reply.

Would moving to develop branch be like:

• new branch from develop:HEAD->develop-max32630fthr-build
• ..merge/cherry-pick changes..
• pull request to develop

I'll see to the mirroring of MAXIM_PATH, and using the regular ARM toolchain. Once I've done that I'll update the port build instructions.

As what goes to the warning it is just saying someones cut the corner by oversimplifying the type of __isr_vector. Once the MAXIM_PATH mirror is in repository I can fix that with a commit:

diff --git a/maxim/Firmware/MAX3263X/Libraries/MAX3263XPeriphDriver/Source/nvic_table.c b/maxim/Firmware/MAX3263X/Libraries/MAX3263XPeriphDriver/Source/nvic_table.c
index d126403..2050b23 100644
--- a/maxim/Firmware/MAX3263X/Libraries/MAX3263XPeriphDriver/Source/nvic_table.c
+++ b/maxim/Firmware/MAX3263X/Libraries/MAX3263XPeriphDriver/Source/nvic_table.c
@@ -63,6 +63,8 @@
 #define __isr_vector __vector_table
 #else
 __attribute__ ((aligned (512)))
+/* defined in startup_<device>.S */
+extern void (* const __isr_vector[])(void);
 #endif
 static void (*ramVectorTable[MXC_IRQ_COUNT])(void);

@@ -75,9 +77,6 @@ static void (*ramVectorTable[MXC_IRQ_COUNT])(void);
 /* ************************************************************************* */
 void NVIC_SetRAM(void)
 {
-    /* should be defined in starup_<device>.S */
-    extern uint32_t __isr_vector;
-
     memcpy(&ramVectorTable, &__isr_vector, sizeof(ramVectorTable));
     SCB->VTOR = (uint32_t)&ramVectorTable;
 }

[mringwal]

Hi

Yes, moving to develop branch should be as easy as doing a rebase on develop branch (since your changes affect a single folder and that hasn't been touch, this should work without any conflicts). If that fails for unknown reasons, I would suggest to cherry-pick the changes onto develop.

Good luck with the update!

[head5man]

Opened a new PR #681 targeting the develop branch.