DISCO_H747I dualcore support #11605

ABOSTM · 2019-10-01T07:33:19Z

Description

Add 2 targets for DISCO_H747I dualcore:

DISCO_H747I -> for CM7 core
DISCO_H747I_CM4 -> for CM4 core

Current restrictions:

TICKLESS deactivated
DeepSleep not supported (DeepSleep wrapped to sleep)

Warning: use of the same IP (example I2C1) by both core at the same time is not prevented,
but is strongly not recommended.
Some Hardware Semaphore are use for common IP, to manage concurrent access by both cores: Flash, GPIO, RCC.

Warning: Drag and drop of binary to DISCO_H747I disk will flash CM7.
In order to flash CM4, one can use STM32 CubeProgrammer tool.
Example of CubeProgrammer command line to flash CM4:
PATH="/c/Program Files/STMicroelectronics/STM32Cube/STM32CubeProgrammer/bin/":$PATH
STM32_Programmer_CLI -c port=SWD mode=UR -w BUILD/DISCO_H747I_CM4/ARM/<binary file name> 0x8100000

Tests executed:

On CM7 (with a blinky binary on CM4), all tests on all 3 toolchains: ARM, GCC_ARM and IAR
On CM4 (with a blinky binary on CM7), all tests on toolchain IAR and GCC_ARM
With toolchain ARM: blinky on both core simultaneously

All tests are passed except:

tests-mbed_hal-sleep_manager
tests-mbed_hal-sleep

This is normal because DeepSleep is not yet supported.

jeromecoutant · 2019-10-01T08:33:12Z

@ARMmbed/team-st-mcd
@MarceloSalazar
@facchinm

jeromecoutant

Regression tests on other targets done.

As explained in the description, CM4 support can not be executed with automatic CI,
but I saw manual tests executed and passed!

Thx @ABOSTM !

ciarmcom · 2019-10-01T09:00:28Z

@ABOSTM, thank you for your changes.
@ARMmbed/mbed-os-maintainers @ARMmbed/mbed-os-tools @ARMmbed/mbed-os-crypto please review.

bulislaw

As far as I can tell, this is sort of a basic support only? It's up to the user to put whatever code on both cores and figure out how do they talk to each other?

bulislaw · 2019-10-01T15:25:15Z

features/mbedtls/targets/TARGET_STM/aes_alt.c

@@ -103,11 +103,19 @@ void mbedtls_aes_free(mbedtls_aes_context *ctx)
    if (ctx == NULL) {
        return;
    }
+#if defined(DUAL_CORE)


@Patater please review

You are right this is up to the user to put whatever on both cores, and to figure out how they could talk to each other.
The modification in this specific file aes_alt.c concerns the potential concurent access (by CM4 and CM7) to common resource (RCC registers). This is done through Hardware Semaphore.

bulislaw · 2019-10-01T15:25:22Z

targets/TARGET_STM/TARGET_STM32H7/TARGET_STM32H747xI/TARGET_DISCO_H747I/PeripheralPins.c

-    {PA_2,       PWM_2,  STM_PIN_DATA_EXT(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF1_TIM2, 3, 0)}, // TIM2_CH3 // Connected to ETH_MDIO
-    {PA_2_ALT0,  PWM_5,  STM_PIN_DATA_EXT(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF2_TIM5, 3, 0)}, // TIM5_CH3 // Connected to ETH_MDIO
-    {PA_2_ALT1,  PWM_15, STM_PIN_DATA_EXT(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF4_TIM15, 1, 0)}, // TIM15_CH1 // Connected to ETH_MDIO
+//    {PA_0,       PWM_2,  STM_PIN_DATA_EXT(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF1_TIM2, 1, 0)}, // TIM2_CH1 // Connected to PMOD\#1- USART2_CTS_NSS


Yes and no...
We used to keep all the lines in all targets .
As the PinMap table is weak, idea was to give the availability for customer to change easily the default choice.

From pin configuration point of view, PA_0 can be connected to TIM2_CH1.
Nevertheless TIM2 and TIM5 are reserved for us_ticker.
That is why thoses lines are commented out: it is nomore usable for PWM purpose.
but we keep those lines as reminder to show the capability.
It is done the same way for example on target NUCLEO_L4R5ZI_P.

Makes sense.

bulislaw

Would it benefit from a readme file in the target directory with description how to build and flash both images?

jeromecoutant · 2019-10-04T09:23:16Z

Would it benefit from a readme file in the target directory with description how to build and flash both images?

Good idea, I will do it asap (in a second time).
Thx

adbridge · 2019-10-07T14:12:28Z

@jeromecoutant is this still waiting for the readme update ?

jeromecoutant · 2019-10-07T14:22:30Z

No...
I will do it in a second time, please start CI

adbridge · 2019-10-07T14:24:54Z

CI started

mbed-ci · 2019-10-07T18:20:19Z

Test run: FAILED

Summary: 1 of 11 test jobs failed
Build number : 1
Build artifacts

Failed test jobs:

jenkins-ci/mbed-os-ci_exporter

jeromecoutant · 2019-10-08T09:50:50Z

Can you start again exporter CI ?

mark-edgeworth

Reviewed only from a tools PoV. Looks ok.

Add 2 targets for DISCO_H747I dualcore: * DISCO_H747I -> for CM7 core * DISCO_H747I_CM4 -> for CM4 core Current restrictions: * TICKLESS deactivated * DeepSleep not supported (DeepSleep wrapped to sleep) Warning: use of the same IP (example I2C1) by both core at the same time is not prevented, but is strongly not recommended. Some Hardware Semaphore are use for common IP, to manage concurrent access by both cores: Flash, GPIO, RCC. Warning: Drag and drop of binary to DISCO_H747I will flash CM7. In order to flash CM4, one can use STM32 CubeProgrammer tool.

…ock.

…tt CPU1

ABOSTM · 2019-10-14T16:08:34Z

Merge conflict solved.

0xc0170 · 2019-10-14T22:06:48Z

CI started

mbed-ci · 2019-10-15T00:38:30Z

Test run: SUCCESS

Summary: 11 of 11 test jobs passed
Build number : 2
Build artifacts

0xc0170 · 2019-10-15T05:48:13Z

I'll review today and merge later.

0xc0170 · 2019-10-15T11:19:53Z

Would it benefit from a readme file in the target directory with description how to build and flash both images?

Was this added, @jeromecoutant @ABOSTM ? Github does not show me any readme file here

0xc0170 · 2019-10-15T11:21:36Z

I can't find docs for DUAL_CORE - what does it do ? When should I use one? (if I edit these changed files, how do I know where I should use this ?)

Readme might answer my questions

jeromecoutant · 2019-10-15T11:24:26Z

DUAL_CORE is set in MCU CMSIS file.

MarceloSalazar · 2019-10-16T08:50:11Z

@0xc0170 can we please merge this for 5.14.1?

0xc0170 · 2019-10-16T09:36:04Z

@0xc0170 can we please merge this for 5.14.1?

The code freeze was the previous week, I set this to 5.14.2 as the next patch release.

jeromecoutant · 2020-02-12T10:28:23Z

Would it benefit from a readme file in the target directory with description how to build and flash both images?

Good idea, I will do it asap (in a second time).
Thx

@bulislaw
Sorry for delay... #12415

jeromecoutant approved these changes Oct 1, 2019

View reviewed changes

ciarmcom requested review from a team October 1, 2019 09:00

ciarmcom requested a review from a team October 1, 2019 09:00

ciarmcom added the needs: review label Oct 1, 2019

bulislaw reviewed Oct 1, 2019

View reviewed changes

bulislaw approved these changes Oct 4, 2019

View reviewed changes

jeromecoutant mentioned this pull request Oct 4, 2019

STM32H747I - DeviceKey is not enabled #11617

Closed

adbridge added scope: new-target needs: CI and removed needs: review labels Oct 7, 2019

mark-edgeworth approved these changes Oct 9, 2019

View reviewed changes

ABOSTM added 4 commits October 14, 2019 18:02

SystemCoreClock should correspond to current core clock and not D1 cl…

48aba33

…ock.

Update HAL/LL EXTI to have default API applied on current core and no…

02cdac5

…tt CPU1

Mbed patch of STM32cube for bootloader: use NVIC_FLASH_VECTOR_ADDRESS

6397a1d

ABOSTM force-pushed the DISCO_H747I_DUALCORE_SUPPORT branch from 6c728de to 6397a1d Compare October 14, 2019 16:06

0xc0170 added ready for merge and removed needs: CI labels Oct 15, 2019

0xc0170 added needs: review and removed ready for merge labels Oct 15, 2019

0xc0170 added ready for merge release-version: 5.14.2 and removed needs: review labels Oct 16, 2019

0xc0170 merged commit 16568da into ARMmbed:master Oct 16, 2019

0xc0170 removed the ready for merge label Oct 16, 2019

jeromecoutant mentioned this pull request Feb 12, 2020

STM32H7 : add readme file for dual core use #12415

Merged

DISCO_H747I dualcore support #11605

DISCO_H747I dualcore support #11605

Uh oh!

Conversation

ABOSTM commented Oct 1, 2019

Description

Tests executed:

Uh oh!

jeromecoutant commented Oct 1, 2019

Uh oh!

jeromecoutant left a comment

Choose a reason for hiding this comment

Uh oh!

ciarmcom commented Oct 1, 2019

Uh oh!

bulislaw left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bulislaw left a comment

Choose a reason for hiding this comment

Uh oh!

jeromecoutant commented Oct 4, 2019

Uh oh!

adbridge commented Oct 7, 2019

Uh oh!

jeromecoutant commented Oct 7, 2019

Uh oh!

adbridge commented Oct 7, 2019

Uh oh!

mbed-ci commented Oct 7, 2019

Uh oh!

jeromecoutant commented Oct 8, 2019

Uh oh!

mark-edgeworth left a comment

Choose a reason for hiding this comment

Uh oh!

ABOSTM commented Oct 14, 2019

Uh oh!

0xc0170 commented Oct 14, 2019

Uh oh!

mbed-ci commented Oct 15, 2019

Uh oh!

0xc0170 commented Oct 15, 2019

Uh oh!

0xc0170 commented Oct 15, 2019

Uh oh!

0xc0170 commented Oct 15, 2019

Uh oh!

jeromecoutant commented Oct 15, 2019

Uh oh!

MarceloSalazar commented Oct 16, 2019

Uh oh!

0xc0170 commented Oct 16, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jeromecoutant commented Feb 12, 2020

Uh oh!

Uh oh!

0xc0170 commented Oct 16, 2019 •

edited

Loading