STM32F7: Add bootloader support #5821

bcostm · 2018-01-10T09:45:04Z

Description

Add bootloader support to the NUCLEO_F746ZG and NUCLEO_F767ZI platforms
Fix issue STM32F7 bootloader does not work #5718 (was related to cache, see questions below)
Tested OK on these 2 platforms using mbed-os-example-bootloader example

Status

READY

Migrations

NO

Open questions concerning Cache

We tried first to disable the caches using the macros:

SCB_InvalidateICache();
SCB_DisableICache();
SCB_CleanInvalidateDCache();
SCB_DisableDCache();

but it didn't work. Do you know why and what is missing ?

We think that the cache activation should be done in another place for example in the platform/mbed_application.c file. What do you think ?

0xc0170 · 2018-01-10T11:28:48Z

/morph build

mbed-ci · 2018-01-10T12:04:19Z

Build : SUCCESS

Build number : 833
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/5821/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build

LMESTM · 2018-01-10T12:19:12Z

@0xc0170 - as mentioned by Bruno we have question regarding the cache management of cortex-M7 MCUs

As of now, cache is enabled in targets/TARGET_STM/mbed_overrides.c. But shouldn't this be generic ?
Also in case of bootloader, shoudn't mbed_start_application handle the cache cleaning / disabling before jumping into new application ?

mbed-ci · 2018-01-10T13:31:43Z

Exporter Build : SUCCESS

Build number : 495
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/5821/

0xc0170 · 2018-01-10T13:36:46Z

As of now, cache is enabled in targets/TARGET_STM/mbed_overrides.c. But shouldn't this be generic ?
Also in case of bootloader, shoudn't mbed_start_application handle the cache cleaning / disabling before jumping into new application ?

Good question, this is not yet covered.

@c1728p9 @bulislaw

@LMESTM generic as handling on architecture level? If it has a cache, do what our specs say (we will review to have this covered)

mbed-ci · 2018-01-10T14:56:55Z

Test : FAILURE

Build number : 673
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/5821/673

0xc0170 · 2018-01-10T15:19:32Z

/morph test

mbed-ci · 2018-01-11T01:11:14Z

Test : FAILURE

Build number : 681
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/5821/681

0xc0170 · 2018-01-11T12:09:57Z

sync device failed (update st link related ? )

/morph test

mbed-ci · 2018-01-11T14:11:25Z

Test : FAILURE

Build number : 683
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/5821/683

0xc0170 · 2018-01-11T15:05:32Z

@bcostm initially it looked like not related sync failure, but might be related - can you reproduce the fialures (sync failues ) for F7 device? same as reported in the test results?

bcostm · 2018-01-12T09:32:44Z

On my side these tests are FAIL on all STM32F7 boards/toolchains::

tests-netsocket-gethostbyname
tests-netsocket-socket_sigio
tests-netsocket-tcp_echo
tests-netsocket-tcp_hello_world

but these tests are PASS on all STM32F7 boards/toolchains:

features-frameworks-utest-tests-unit_tests-test_setup_case_selection_failure
tests-mbedtls-multi
tests-mbedmicro-mbed-static_assert
features-frameworks-utest-tests-unit_tests-basic_test

PS: I am waiting test results on the master branch to compare.

bcostm · 2018-01-15T09:20:33Z

I have relaunched the above tests several times using this branch and master branch on all F7 platforms/toolchains: the netsockets tests are unstable (SYNC_FAILED or OK), all the other tests are OK. Can you relaunch the mbed-ci tests ?

0xc0170 · 2018-01-15T11:25:19Z

What is causing the sync failed ?

/morph test

mbed-ci · 2018-01-15T14:46:44Z

Test : FAILURE

Build number : 711
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/5821/711

mprse · 2018-01-16T07:29:49Z

bcostm:add_BL_nucleo-f746zg branch contains old version of tests-mbed_hal-rtc_time_conv test (it has been recently optimised), but this does not explain why ASSERT fails.
I tried to run it few times on master and on bcostm:add_BL_nucleo-f746zg branch and on both it works.
It looks like there is some inconsistency between host part of the test and mbed part in CI.
I think that at first bcostm:add_BL_nucleo-f746zg should be re-based on current master and we should try again with morph test.

bcostm · 2018-01-16T08:11:53Z

Rebase done.

0xc0170 · 2018-01-16T08:17:24Z

/morph build

mbed-ci · 2018-01-16T08:47:14Z

Build : SUCCESS

Build number : 873
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/5821/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build

mbed-ci · 2018-01-16T09:52:22Z

Exporter Build : SUCCESS

Build number : 544
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/5821/

mbed-ci · 2018-01-16T10:51:20Z

Test : FAILURE

Build number : 719
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/5821/719

mprse · 2018-01-16T10:55:52Z

It looks like all PASSED, but status is FAILURE...
tests-mbed_hal-rtc_time_conv test issue has been solved (this might be some kind of CI bug).

0xc0170 · 2018-01-16T11:12:09Z

It was unfortunately aborted but results looked good !

/morph test

The mbed_sdk_init can be called either during cold boot or during application boot after bootloader has been executed. In case the bootloader has already enabled the cache, is is needed to not enable it again.

bcostm · 2018-01-22T10:15:54Z

I can't see the log files. Which test is causing this comm error ?

0xc0170 · 2018-01-22T12:16:03Z

I can't see the log files. Which test is causing this comm error ?

I sent it to you via email, I could not locate them neither via the test log log url.

bcostm · 2018-01-22T16:02:27Z

As discussed by email, no sync error on my side.

I have upgraded the NUCLEO_F746ZG board with STLink fw V2.J30.M19 and all mbedOS5 tests are PASS for me.

0xc0170 · 2018-01-23T07:59:57Z

/morph build

mbed-ci · 2018-01-23T08:31:37Z

Build : SUCCESS

Build number : 914
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/5821/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build

mbed-ci · 2018-01-23T09:30:40Z

Test : SUCCESS

Build number : 756
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/5821/756

mbed-ci · 2018-01-23T09:58:10Z

Exporter Build : SUCCESS

Build number : 595
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/5821/

0xc0170 · 2018-01-23T13:49:05Z

/morph uvisor-test

0xc0170 · 2018-01-23T13:50:22Z

Test passed, updating firmware helped ! 🤞

raghidmardini · 2018-01-23T19:23:30Z

I'm seeing an issue with the changes made to the target NUCLEO_F767ZI when constructing an SPI object.

The following code was tested on mbed-os-5.7.3 and the LEDs blinked indefinitely while creating SPI objects.

After updating to the merged commit 4c07c1c, initially the LEDs blinked indefinitely, but after disconnecting the device from power and repowering it, the code hanged at "Constructing SPI" message.

If I undo the changed made to the file targets/TARGET_STM/mbed_overrides.c, the code runs fine again. It seems like the Cache is not enabled correctly.

EDIT: I am using the latest st-link firmware V2J30M19

#include "mbed.h"

DigitalOut led1 (LED1,0);
DigitalOut led2 (LED2,0);
DigitalOut led3 (LED3,0);

int main(){
	while(true){
		led1=!led1;
		wait(0.2);
		led2=!led2;
		wait(0.2);
		led2=!led3;
		wait(0.2);
		printf("Constructing SPI\n\r");
		SPI spi(PC_12, PC_11, PC_10);
		printf("Constructed SPI\n\r");
	}
}

cmonr · 2018-01-23T21:05:14Z

@raghidmardini Please open a new issue for this particular problem. In general, pull requests are left alone after its either merged or closed.

However, feel free to reference this pull request.

0xc0170 added the needs: review label Jan 10, 2018

0xc0170 approved these changes Jan 10, 2018

View reviewed changes

0xc0170 added needs: CI and removed needs: review labels Jan 10, 2018

0xc0170 added needs: work and removed needs: CI labels Jan 11, 2018

bcostm force-pushed the add_BL_nucleo-f746zg branch from d550840 to eed1b8e Compare January 16, 2018 08:11

bcostm added 4 commits January 22, 2018 11:11

BL NUCLEO_F746ZG: enable bootloader

96dc537

BL NUCLEO_F746ZG: change scb->vector assignment

43f4b67

Check cache before enabling it

6edcc1e

The mbed_sdk_init can be called either during cold boot or during application boot after bootloader has been executed. In case the bootloader has already enabled the cache, is is needed to not enable it again.

NUCLEO_F767ZI: Add bootloader support

4d0535a

bcostm force-pushed the add_BL_nucleo-f746zg branch from eed1b8e to 4d0535a Compare January 22, 2018 14:13

0xc0170 added needs: CI and removed needs: work labels Jan 23, 2018

0xc0170 added ready for merge release-version: 5.7.4 and removed needs: CI labels Jan 23, 2018

cmonr merged commit 4c07c1c into ARMmbed:master Jan 23, 2018

cmonr removed the ready for merge label Jan 23, 2018

jeromecoutant mentioned this pull request Jan 24, 2018

STM32F7 bootloader does not work #5718

Closed

cmonr mentioned this pull request Jan 25, 2018

Revert "NUCLEO_F767ZI: Add bootloader support" #5927

Closed

MikeDK mentioned this pull request Jan 25, 2018

CriticalSectionLock: fixing missing include #5912

Merged

0xc0170 mentioned this pull request Jan 25, 2018

Revert "STM32F7: Add bootloader support" #5932

Merged

bcostm mentioned this pull request Jan 30, 2018

STM32F7: Add bootloader support (new trial) #5972

Merged

bcostm deleted the add_BL_nucleo-f746zg branch March 21, 2018 09:25

bcostm mentioned this pull request Jun 6, 2018

MBED hangs during bootloader program jump while using rtos #1666

Closed

STM32F7: Add bootloader support #5821

STM32F7: Add bootloader support #5821

Uh oh!

Conversation

bcostm commented Jan 10, 2018

Description

Status

Migrations

Open questions concerning Cache

Uh oh!

0xc0170 commented Jan 10, 2018

Uh oh!

mbed-ci commented Jan 10, 2018

Triggering tests

Uh oh!

LMESTM commented Jan 10, 2018

Uh oh!

mbed-ci commented Jan 10, 2018

Uh oh!

0xc0170 commented Jan 10, 2018

Uh oh!

mbed-ci commented Jan 10, 2018

Uh oh!

0xc0170 commented Jan 10, 2018

Uh oh!

mbed-ci commented Jan 11, 2018

Uh oh!

0xc0170 commented Jan 11, 2018

Uh oh!

mbed-ci commented Jan 11, 2018

Uh oh!

0xc0170 commented Jan 11, 2018

Uh oh!

bcostm commented Jan 12, 2018

Uh oh!

bcostm commented Jan 15, 2018

Uh oh!

0xc0170 commented Jan 15, 2018

Uh oh!

mbed-ci commented Jan 15, 2018

Uh oh!

mprse commented Jan 16, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bcostm commented Jan 16, 2018

Uh oh!

0xc0170 commented Jan 16, 2018

Uh oh!

mbed-ci commented Jan 16, 2018

Triggering tests

Uh oh!

mbed-ci commented Jan 16, 2018

Uh oh!

mbed-ci commented Jan 16, 2018

Uh oh!

mprse commented Jan 16, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

0xc0170 commented Jan 16, 2018

Uh oh!

bcostm commented Jan 22, 2018

Uh oh!

0xc0170 commented Jan 22, 2018

Uh oh!

bcostm commented Jan 22, 2018

Uh oh!

0xc0170 commented Jan 23, 2018

Uh oh!

mbed-ci commented Jan 23, 2018

Triggering tests

Uh oh!

mbed-ci commented Jan 23, 2018

Uh oh!

mbed-ci commented Jan 23, 2018

Uh oh!

0xc0170 commented Jan 23, 2018

Uh oh!

0xc0170 commented Jan 23, 2018

Uh oh!

raghidmardini commented Jan 23, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

mprse commented Jan 16, 2018 •

edited

Loading

mprse commented Jan 16, 2018 •

edited

Loading

raghidmardini commented Jan 23, 2018 •

edited

Loading