STM32L1 Flash API and xDot bootloader support #4640

chrissnow · 2017-06-26T22:21:32Z

Description

Flash API for STM32L1
xDot support for bootloaders

Status

READY

in support of #4534

LMESTM · 2017-06-27T06:35:00Z

@chrissnow thanks for pushing this support. I'll make a short review of it.
Could you run the test cases related to flash and share the results ?
tests-mbed_drivers-flashiap
tests-mbed_hal-flash

chrissnow · 2017-06-27T07:32:52Z

@LMESTM I will try and run those today. Clearing of flags in the erase routine I wasn't sure of. Other than sector size it's basically the L0 code.

@mfiore02 please could you review the xDot changes?

0xc0170 · 2017-06-27T08:00:58Z

targets/TARGET_STM/TARGET_STM32L1/flash_api.c

+    return 0;
+}
+
+uint32_t flash_get_sector_size(const flash_t *obj, uint32_t address) {


Please fix the formatting for some functions, { for the body of the function starts on the new line

@LMESTM this was taken from the L0 so should probably go there too.

@chrissnow ok thanks !

chrissnow · 2017-06-27T10:11:40Z

@LMESTM results from tests

| target              | platform_name | test suite                  | test case                 | passed | failed | result | elapsed_time (sec) |
+---------------------+---------------+-----------------------------+---------------------------+--------+--------+--------+--------------------+
| XDOT_L151CC-GCC_ARM | XDOT_L151CC   | tests-mbed_drivers-flashiap | FlashIAP - init           | 1      | 0      | OK     | 0.05               |
| XDOT_L151CC-GCC_ARM | XDOT_L151CC   | tests-mbed_drivers-flashiap | FlashIAP - program        | 1      | 0      | OK     | 3.5                |
| XDOT_L151CC-GCC_ARM | XDOT_L151CC   | tests-mbed_drivers-flashiap | FlashIAP - program errors | 1      | 0      | OK     | 0.06               |
+---------------------+---------------+-----------------------------+---------------------------+--------+--------+--------+--------------------+

+---------------------+---------------+----------------------+-------------------------------+--------+--------+--------+--------------------+
| target              | platform_name | test suite           | test case                     | passed | failed | result | elapsed_time (sec) |
+---------------------+---------------+----------------------+-------------------------------+--------+--------+--------+--------------------+
| XDOT_L151CC-GCC_ARM | XDOT_L151CC   | tests-mbed_hal-flash | Flash - buffer alignment test | 1      | 0      | OK     | 0.96               |
| XDOT_L151CC-GCC_ARM | XDOT_L151CC   | tests-mbed_hal-flash | Flash - clock and cache test  | 1      | 0      | OK     | 0.34               |
| XDOT_L151CC-GCC_ARM | XDOT_L151CC   | tests-mbed_hal-flash | Flash - erase sector          | 1      | 0      | OK     | 0.11               |
| XDOT_L151CC-GCC_ARM | XDOT_L151CC   | tests-mbed_hal-flash | Flash - init                  | 1      | 0      | OK     | 0.33               |
| XDOT_L151CC-GCC_ARM | XDOT_L151CC   | tests-mbed_hal-flash | Flash - mapping alignment     | 1      | 0      | OK     | 0.06               |
| XDOT_L151CC-GCC_ARM | XDOT_L151CC   | tests-mbed_hal-flash | Flash - program page          | 1      | 0      | OK     | 0.58               |
+---------------------+---------------+----------------------+-------------------------------+--------+--------+--------+--------------------+

@0xc0170 formatting has been tidied as requested.

mfiore02 · 2017-06-27T16:03:05Z

I have a couple comments/questions:

Assuming normal builds for xDot will continue to behave as they have been (compiled for no bootloader). Is this correct?
If MTS desires to write our own bootloader in the future and include it by default in xDot compiles, how can we architect that so that either bootloader could be used? Is there a way to disable the hooks that offset the application (linker files & vector table address) and combine the bootloader (post build hooks)? So either bootloader (or no bootloader) could be used? This might be a nice change to backport to mDot and Dragonfly as well (our other boards with a bootloader). A bit of a rabbit trail, but I think it's worth considering.
I only see changes to the ARM linker file to support building the bootloader. Why not support it with GCC and/or IAR as well? Not everyone has an ARM license, so at least adding GCC support would be nice.

chrissnow · 2017-06-27T16:24:24Z

@mfiore02
Normal builds are unaffected, the changes don't actually enable\merge a bootloader it just adds support for one, you need to define one in "mbed_app.json" such as

{
    "target_overrides": {
        "K64F": {
            "target.bootloader_img": "bootloader/K64F.bin"
        },
        "NUCLEO_F429ZI": {
            "target.bootloader_img": "bootloader/NUCLEO_F429ZI.bin"
        },
        "UBLOX_EVK_ODIN_W2": {
            "target.bootloader_img": "bootloader/UBLOX_EVK_ODIN_W2.bin"
        },
        "XDOT_L151CC": {
            "target.bootloader_img": "bootloader/xDot.bin"
        }
    }
}

if MTS make their own you would just point that to your bootloader bin, the build tools then seem to find its size, sort's out the linker etc then merge it at the end. without "target.bootloader_img" nothing changes.

MTS would just need to default that to your bin.

The bootloader build uses mbed_app.json again but just to fix the size of the bootloader so it can be padded.

    "target_overrides": {
        "K64F": {
            "target.restrict_size": "0x40000"
        },
        "NUCLEO_F429ZI": {
            "target.restrict_size": "0x40000"
        },
        "UBLOX_EVK_ODIN_W2": {
            "target.restrict_size": "0x40000"
        },
        "XDOT_L151CC": {
            "target.restrict_size": "0x10000"
        },
		"*": {
            "platform.stdio-flush-at-exit": false
        }
    },
    "config": {
        "update_file": "\"/disk/app.bin\""
    }, "macros": [ 
        "NDEBUG=1"
    ]
}

I forgot to sort out GCC + IAR linker, I will take a look tonight.

I hope that makes some sense!
#4534 might help explain things.

mfiore02 · 2017-06-27T17:45:08Z

@chrissnow thanks, that answers my questions. I'm OK with these changes once GCC is added as a build option.

theotherjimmy · 2017-06-27T18:43:45Z

@chrissnow I would like to see IAR supported as well, as supporting only ARM and GCC_ARM could lead to hard to debug failures when someone attempts to use this bootloader support on IAR.

mfiore02 · 2017-06-27T19:55:11Z

LGTM!

LMESTM

Only 2 comments in code to be removed or updated

LMESTM · 2017-06-28T06:56:56Z

targets/TARGET_STM/TARGET_STM32L1/flash_api.c

+
+uint32_t flash_get_sector_size(const flash_t *obj, uint32_t address) 
+{
+    /*  considering 1 sector = 1 page */


This comment is not valid.
Tt actually comes from L4 where the assumption is true.
Then the code was copied and modified for L0 where all sectors are 32 pages - so the comment should have been removed in L0 - I will do it.
Now this is copied in L1 but is not true either - so needs to be removed

LMESTM · 2017-06-28T06:57:19Z

targets/TARGET_STM/TARGET_STM32L1/flash_api.c

+
+uint32_t flash_get_page_size(const flash_t *obj)
+{
+    /*  considering 1 sector = 1 page */


chrissnow · 2017-06-28T08:36:01Z

@LMESTM comments removed as requested.

theotherjimmy · 2017-06-28T14:38:40Z

@chrissnow I merged #4610 and it has caused a merge conflict on this PR. Could you rebase?

theotherjimmy · 2017-06-28T15:05:02Z

@chrissnow It looks like something went wrong with your rebase. We cannot backport to a release any PRs that have merge commits on them. Could you rebase to remove that merge commit?

chrissnow · 2017-06-28T15:11:12Z

@theotherjimmy yes that didn't do what I was expecting!

theotherjimmy · 2017-06-28T15:12:29Z

I recommend marking the current branch with another branch in case things don't go as planned again.

chrissnow · 2017-06-28T15:42:05Z

@theotherjimmy any suggestions for what git commands to run? I seems to be digging a bigger hole at the moment!

theotherjimmy · 2017-06-28T15:44:11Z

I'd try

git branch xDot-Bootloader-bak
git fetch origin
git rebase origin/master

Assuming that origin points to ARMmbed/mbed-os.

chrissnow · 2017-06-28T15:56:46Z

thoughts on this?

Auto-merging features/mbedtls/targets/TARGET_STM/TARGET_STM32F4/TARGET_NUCLEO_F439ZI/mbedtls_device.h
CONFLICT (content): Merge conflict in features/mbedtls/targets/TARGET_STM/TARGET_STM32F4/TARGET_NUCLEO_F439ZI/mbedtls_device.h
error: Failed to merge in the changes.
Patch failed at 0095 NUCLEO_F429ZI/mbedtls: add SHA1 hw_acceleration
The copy of the patch that failed is found in: .git/rebase-apply/patch

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".

theotherjimmy · 2017-06-28T16:03:11Z

@chrissnow Something looks wrong. You should not need to apply that patch; it's already on master.

theotherjimmy · 2017-06-28T16:07:52Z

I'm going to give it a go real quick. I'll link my branch if I succeed

theotherjimmy · 2017-06-28T16:13:37Z

@chrissnow I think that's related to doing git rebase master and your master branch being very behind. I just ran into the same merge conflict, and that was why.

I corrected it by aborting the rebase (git rebase --abort) and then updating my master branch (git checkout master, git pull origin master). Then I retried the rebase (git checkout xDot-Bootloader, git rebase master) and got a merge conflict on your first commit in targets.json, which I expected to happen.

chrissnow · 2017-06-28T17:12:03Z

@theotherjimmy I hope that is now sorted out, Thanks for the assistance.

theotherjimmy · 2017-06-28T17:36:48Z

@chrissnow It looks like you pulled and merged instead of force pushing.

theotherjimmy · 2017-06-28T17:37:12Z

You end up with a merge commit, and duplicate commits that way!

theotherjimmy · 2017-06-28T17:43:48Z

Supposing that the log up to 4b59838 is correct:

git checkout 4d59838774ff28c480f84b9ebfe86946e9cca423

checkout out the repo just before the merge commit, and after the rebase

git branch -D xDot-Bootloader

Kill the old branch

git checkout -b xDot-Bootloader

recreate the branch using the correct head

git push -f -u chrissnow

Push the new history to this PR (supposing that chrissnow is the remote for chrissnow/mbed-os)

chrissnow · 2017-06-29T08:56:17Z

@0xc0170 PR #4666 submitted.

Attempt to add flash API but not working properly

chrissnow · 2017-07-13T19:42:36Z

@theotherjimmy this should be good to go now #4666 is merged.

theotherjimmy · 2017-07-13T20:10:41Z

@chrissnow Agreed. Removing preceding PR tag

/morph test

mbed-bot · 2017-07-14T01:54:47Z

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 810

All builds and test passed!

STM32L1 Flash API and xDot bootloader support

0xc0170 reviewed Jun 27, 2017

View reviewed changes

0xc0170 added the needs: review label Jun 27, 2017

theotherjimmy approved these changes Jun 27, 2017

View reviewed changes

theotherjimmy added needs: CI and removed needs: review labels Jun 27, 2017

LMESTM approved these changes Jun 28, 2017

View reviewed changes

chrissnow force-pushed the xDot-Bootloader branch from b684d2a to 4d59838 Compare June 28, 2017 18:15

chrissnow added 13 commits June 30, 2017 22:25

initial commit of xDot bootloader

c1e32a7

added flash algorithm

1899841

VTOR bootloader aware

0ff0551

Attempt to add flash API but not working properly

GCC_ARM VTOR fixed, doesnt fit in the bootloader region though..

802000b

clear additional flags on erase to prevent errors

5803bdd

added missing FLASH_FLAG_OPTVERR

65ab955

Formatting tidy up.

ed51bcb

uArm Bootloader support

a4c7a29

IAR Bootloader support

82a33b2

GCC Bootloader support

8484467

Incorrect comments removed.

e59c059

Code tidy

a516dca

Tidy from rebase

2a2d904

chrissnow force-pushed the xDot-Bootloader branch from 45b7dd0 to 2a2d904 Compare June 30, 2017 21:32

theotherjimmy added the needs: preceding PR label Jul 10, 2017

theotherjimmy removed the needs: preceding PR label Jul 13, 2017

theotherjimmy added ready for merge and removed needs: CI labels Jul 17, 2017

theotherjimmy merged commit 6593d5b into ARMmbed:master Jul 17, 2017

theotherjimmy added ready for merge release-version: 5.5.4 and removed ready for merge labels Jul 17, 2017

janjongboom pushed a commit to janjongboom/mbed-os that referenced this pull request Aug 8, 2017

Merge pull request ARMmbed#4640 from chrissnow/xDot-Bootloader

e2eb9b3

STM32L1 Flash API and xDot bootloader support

janjongboom pushed a commit to janjongboom/mbed-os that referenced this pull request Aug 8, 2017

Merge pull request ARMmbed#4640 from chrissnow/xDot-Bootloader

e9e233d

STM32L1 Flash API and xDot bootloader support

chrissnow mentioned this pull request Oct 17, 2017

LPC1769 port #5025

Merged

STM32L1 Flash API and xDot bootloader support #4640

STM32L1 Flash API and xDot bootloader support #4640

Uh oh!

Conversation

chrissnow commented Jun 26, 2017

Description

Status

Uh oh!

LMESTM commented Jun 27, 2017

Uh oh!

chrissnow commented Jun 27, 2017

Uh oh!

0xc0170 Jun 27, 2017

Choose a reason for hiding this comment

Uh oh!

chrissnow Jun 28, 2017

Choose a reason for hiding this comment

Uh oh!

LMESTM Jun 28, 2017

Choose a reason for hiding this comment

Uh oh!

chrissnow commented Jun 27, 2017

Uh oh!

mfiore02 commented Jun 27, 2017

Uh oh!

chrissnow commented Jun 27, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mfiore02 commented Jun 27, 2017

Uh oh!

theotherjimmy commented Jun 27, 2017

Uh oh!

mfiore02 commented Jun 27, 2017

Uh oh!

LMESTM left a comment

Choose a reason for hiding this comment

Uh oh!

LMESTM Jun 28, 2017

Choose a reason for hiding this comment

Uh oh!

LMESTM Jun 28, 2017

Choose a reason for hiding this comment

Uh oh!

chrissnow commented Jun 28, 2017

Uh oh!

theotherjimmy commented Jun 28, 2017

Uh oh!

theotherjimmy commented Jun 28, 2017

Uh oh!

chrissnow commented Jun 28, 2017

Uh oh!

theotherjimmy commented Jun 28, 2017

Uh oh!

chrissnow commented Jun 28, 2017

Uh oh!

theotherjimmy commented Jun 28, 2017

Uh oh!

chrissnow commented Jun 28, 2017

Uh oh!

theotherjimmy commented Jun 28, 2017

Uh oh!

theotherjimmy commented Jun 28, 2017

Uh oh!

theotherjimmy commented Jun 28, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

chrissnow commented Jun 28, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

theotherjimmy commented Jun 28, 2017

Uh oh!

theotherjimmy commented Jun 28, 2017

Uh oh!

theotherjimmy commented Jun 28, 2017

Uh oh!

chrissnow commented Jun 29, 2017

Uh oh!

chrissnow commented Jul 13, 2017

Uh oh!

theotherjimmy commented Jul 13, 2017

chrissnow commented Jun 27, 2017 •

edited

Loading

theotherjimmy commented Jun 28, 2017 •

edited

Loading

chrissnow commented Jun 28, 2017 •

edited

Loading