Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stm32 flash update #4980

Merged
merged 9 commits into from
Sep 4, 2017
Merged

Stm32 flash update #4980

merged 9 commits into from
Sep 4, 2017

Conversation

LMESTM
Copy link
Contributor

@LMESTM LMESTM commented Aug 28, 2017

Description

Several updates concerning Flash API support on STM32 targets.

Status

READY

TESTS

tests-mbed_drivers-flashiap and tests-mbed_hal-flash PASSED OK on ARM and GCC-ARM on L0, L1, L4, F4 and F7 STM32 targets.

reports.zip

First add the flash_data.h that describe the flash memory topology,
and also activate FLASH support for the corresponding targets.
First add the flash_data.h that describe the flash memory topology,
and also activate FLASH support for the corresponding targets.
First add the flash_data.h that describe the flash memory topology,
and also activate FLASH support for the corresponding targets.
First add the flash_data.h that describe the flash memory topology,
and also activate FLASH support for the corresponding targets.

This is a 1,5MB flash memory device which contains 15 sectors, where
sectors 12 to 15 are 128KB sectors. So flash_api.c needed has been
updated to differentiate between this flash memory and the 2MB ones
by checking existence of sector 16 instead of sector 12.
Users of FlashIAP usually get the minimum programable size
by calling flash.get_page_size(), so let's return the minimum
to allows a most efficient usage of flash.

For F4 devices, this is 1 byte.
For L0 and L1 devices, this is a word (4 bytes).
For L4 devices, this is a double word (8 bytes).
Adding flash API support to STM32F7 family. The code is derived from
F4 family one. The memory topology is described in flash_data.h files
and the flash_api.c implementation manages the 2 possible memory types (1
or 2 banks).
In case the target supports a page size of 1 byte, i.e. is able to
program flash 1 byte at a time, which is the case of STM32 F4 targets,
there is no reason for flash_device.program to return an error when
trying to write on an "unaligned" address.
There was a comilation error for NUCLeO_F410RB as it does not have
a ADDR_FLASH_SECTOR_5.
@0xc0170
Copy link
Contributor

0xc0170 commented Aug 31, 2017

cc @c1728p9

@studavekar
Copy link
Contributor

/morph test

@mbed-bot
Copy link

mbed-bot commented Sep 2, 2017

Result: FAILURE

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

/morph test

Output

mbed Build Number: 1166

Example Build failed!

@studavekar
Copy link
Contributor

Above failure was due to jerkins too many files open

java.io.FileNotFoundException: /var/lib/jenkins/jobs/examples_build_matrix/configurations/axis-target/ARCH_PRO/axis-toolchain/ARM/builds/900/changelog.xml (Too many open files)
	at java.io.FileOutputStream.open0(Native Method)
	at java.io.FileOutputStream.open(FileOutputStream.java:270)
	at java.io.FileOutputStream.<init>(FileOutputStream.java:213)
	at java.io.FileOutputStream.<init>(FileOutputStream.java:162)
	at java.io.FileWriter.<init>(FileWriter.java:90)

/morph test

@mbed-bot
Copy link

mbed-bot commented Sep 2, 2017

Result: SUCCESS

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

/morph test

Output

mbed Build Number: 1179

All builds and test passed!

@adbridge
Copy link
Contributor

This relies on changes made in #4920 which is scheduled for 5.6 as it changes behaviour. Thus this PR will have to go into 5.6.1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants