cpu/stm32: cleanup interrupt vectors

[aabadie]

After doing this for stm32f7 family in #6991, I though it would be nice to do it for the others family.

The strategy is the same:

• I split isr definitions for each cpu type, trying to keep the vectors.c as readable as possible.

#if defined(CPU_MODEL_STM32FXXX)
...
(void*) isr_xxx,  /* [i] interrupt comment*/
...
#eilf defined(CPU_MODEL_STM32FYYY)
...
(void*) isr_jjj,  /* [j] interrupt comment*/
...

• Added comments for each line with the interrupt number: this simplify readability, I think and hence maintainability

While working on this, some issues were fixed:

• wrong number of IRQ for some cpus
• isr not defined, or defined whereas not available (I don't have the full list but there quite a few in this case)

Boards/CPU to test (feel free to add any missing ones):

• F0:
• Nucleo 32 F031 (@aabadie)
• Nucleo 32 F042 (@aabadie)
• Nucleo 64 F030 (@aabadie)
• Nucleo 64 F070 (@aabadie)
• Nucleo 64 F072 (@aabadie)
• Nucleo 64 F091 (@aabadie)
• stm32f0discovery (@haukepetersen)
• F1:
• Nucleo 64 F103 (@aabadie)
• iotlab-m3
• F2:
• Nucleo 144 F207 (@aabadie)
• F3:
• Nucleo 32 F303 (@aabadie)
• Nucleo 64 F302 (@aabadie)
• Nucleo 64 F303 (@aabadie)
• Nucleo 64 F334 (@aabadie)
• Nucleo 144 F303 (@aabadie)
• stm32f3discovery (@haukepetersen)
• F4:
• Nucleo 64 F401 (@vincent-d)
• Nucleo 64 F410 (@aabadie)
• Nucleo 64 F411 (@aabadie)
• Nucleo 64 F446 (@aabadie)
• Nucleo 144 F412 (@aabadie)
• Nucleo 144 F413 (@vincent-d)
• Nucleo 144 F429 (@aabadie)
• Nucleo 144 F446 (@aabadie)
• stm32f4discovery (@haukepetersen)
• L0:
• Nucleo 32 L031 (@aabadie) (seems broken on master)
• Nucleo 64 L053 (@aabadie) shell broken fixed
• Nucleo 64 L073 (@aabadie)
• b-l072z-lrwan1 (@aabadie)
• L1:
• Nucleo 64 L152 (@aabadie)
• nz32-sc151 (@aabadie)
• L4:
• Nucleo 32 L432 (@aabadie)
• Nucleo 64 L476 (@aabadie)
• F7:
• Nucleo 144 F722 (@aabadie)
• Nucleo 144 F746
• Nucleo 144 F767 (@aabadie)

[haukepetersen]

I am not sure if we can't do better, I think this is definitively a big improvement in terms of readability (and just see the number of bugs found with this refactoring...). So for now I like the PR.

@vincent-d what do you say about it?

[aabadie]

I am not sure if we can't do better

Agreed, and I didn't want this PR to be the ultimate solution. I already tried different things in #6617 but none were accepted (for many reasons).
At least, as you said, here we have something readable, where all types of MCU are correctly configured (I hope). It will make things simpler if one day we find a better solution

[vincent-d]

I like it! It's much easier to read than before (thanks to the [i] comment I guess).

[vincent-d]

Missing newline

[aabadie]

Fixed, directly squashed

[aabadie]

This is wrong: should be CPU_MODEL_STM32L432KC

[haukepetersen]

As said, I also like it. But before giving my ACK, I would like to do some more intensive testing, as this PR has means to break quite a bit of boards :-) Should we somehow synchronize testing efforts?

[aabadie]

Should we somehow synchronize testing efforts?

That would be good indeed :)
I edited the PR comment with a first list of boards but maybe I missed some.

[aabadie]

Another question: what kind of tests ? (all configured periph tests I guess ?)

[haukepetersen]

we can't test everything, but testing the default example (incl. SAUL mappings to the button) and maybe a timer test for selected boards together with a thorough code review should do the trick.

[haukepetersen]

Confirmed working on the discovery boards.

I think we have covered enough boards to verify this PR, so we can safely merge this.

[haukepetersen]

ACK after giving this another thorough review. Still amazing how many miss-configurations we had in the code before...

[aabadie]

I think we have covered enough boards to verify this PR, so we can safely merge this.

+1

[haukepetersen]

and go.