Update all STM32 HALs as submodules

[JohnK1987]

Summary of changes

This PR brings update of all STM32 HALs and moreover HALs of all families were switched to submodules. That brings possibility of easy switch between HAL versions, easy update and save a lot of disk space.

Impact of changes

• update of all current STM32 HALs
• all STM32 HALs are submodules now (this will save a lot of space in combination with Add submodule manager script #523)
• new HALs for N6 and U3 families were added for future

When some patches will be necessary then we will use this approach.

1. copy of file that we want to patching and place it into STM32Cube_FW\Mbed_HAL_overrides
2. apply the patch
3. change path of that file in STM32Cube_FW/CMakeLists.txt

For examples see STM32G4

Migration actions required

Documentation

---

Pull request type

[x] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

---

Test results

[] No Tests required for this change (E.g docs only update)
[x] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

---

[JohnK1987]

I did some research about applied patches in old HALs, how Jamie recommended.
Just few were found. Some of them are already implemented in new versions of HALs and two not

• STM32G4 from errata - already implemented via method descripted above
• DMA fifo issue, but here I am feeling like in a endless loop or circle

This similar patch was applied for F2,F4,F7,H7 in the past.

Affected files were xxx_hal_dma.c or/and xxx_hal_dma_ex.c is some cases.

Latest HALs
mbed-os\targets\TARGET_STM\TARGET_STM32F2\STM32Cube_FW\stm32f2xx-hal-driver\Src\stm32f2xx_hal_dma_ex.c
205,19: hdma->Instance->FCR |= DMA_IT_FE;
mbed-os\targets\TARGET_STM\TARGET_STM32F4\STM32Cube_FW\stm32f4xx-hal-driver\Src\stm32f4xx_hal_dma_ex.c
204,19: hdma->Instance->FCR |= DMA_IT_FE;
mbed-os\targets\TARGET_STM\TARGET_STM32F7\STM32Cube_FW\stm32f7xx-hal-driver\Src\stm32f7xx_hal_dma_ex.c
199,19: hdma->Instance->FCR |= DMA_IT_FE;
mbed-os\targets\TARGET_STM\TARGET_STM32F7\STM32Cube_FW\stm32f7xx-hal-driver\Src\stm32f7xx_hal_dma.c
482,19: hdma->Instance->FCR |= DMA_IT_FE;
mbed-os\targets\TARGET_STM\TARGET_STM32H7\STM32Cube_FW\stm32h7xx-hal-driver\Src\stm32h7xx_hal_dma_ex.c
292,47: ((DMA_Stream_TypeDef *)hdma->Instance)->FCR |= DMA_IT_FE;

The fix aplied in xxx_hal_dma_ex.c is in function HAL_DMAEx_MultiBufferStart_IT what is called only in HAL_DCMI_Start_DMA. However I did not found any other calls of these functions across Mbed.

The fix aplied in xxx_hal_dma.c is in function HAL_DMA_Start_IT that is used across many peripherals.

But ST's employee gave an answer to Jamie about the issue should be solved in HAL PPP drivers and really in STM32H7 SPI HAL driver is same function (SPI_DMAError) like the guy from ST posted. Unfortunately this functions was there years ago, so question is if this is really a solution...

@multiplemonomials Mbed releted seems to be only implementation of STM32F7 because only for this one I found a conection to Mbed drivers. Of course I can be wrong and missed something.
Let me know your opinion. Then I can create necessary patches and move on.

[multiplemonomials]

OK I did a little digging, and you are right, this seems to be STM32F7 specific. The H7 HAL has this line: https://github.com/STMicroelectronics/stm32h7xx-hal-driver/blob/8bd31106a890ae7254f757bbe55d467a52cc8e03/Src/stm32h7xx_hal_spi.c#L3523

Which would appear to prevent this issue from happening. I didn't realize this when I filed the issue on the H7 repo. But the F7 HAL does not: https://github.com/STMicroelectronics/stm32f7xx-hal-driver/blob/40630a2df5e6a0536e0fb37c39a4fb968f3364d4/Src/stm32f7xx_hal_spi.c#L3375

So we will need to keep this patch applied for STM32F7 (and any others that do not have that if statement but do have FIFO error flags). Maybe you could file an issue on that repo linking to my original issue?