[Keil5] several configs for STM32xxx targets

[ohagendorf]

• adding uvision5 configs to several STM32xx targets
• all configs are tested through exporting BLINKY + additional printf() to Keil5, compiling und flashing - everything was OK
• additional template with enabled option Use Cross-Compile Optimization (NUCLEO_F042 can't be used without this option because flash is too small)

Please see PR #1745: That pull request was closed because the changes in targets.py/targets.json. This PR is the same but using the new format.

@0xc0170 asked for a change to ARM instead of uARM. That is not possible because:

• scatter file for ARM is not correct
• after changing the scatter file using the uARM as a guideline the projects are not running
• so changing to ARM should be a future work

[ohagendorf]

To test this you need PR #1829 or a NDEBUG define.

[ohagendorf]

Anything news about this?

[0xc0170]

so changing to ARM should be a future work

Create an issue for this please if there's is not yet.

A target which has >= 64k Flash should use ARM lib. Therefore I dont think some changes here for devices like F4/F7 what we want. uARM is not thread safe, limited functionality. However, you haven't changed default toolchain,just providing aligned exporters. I'll have closer look this weekend, and will get back.

cc @sg-

[0xc0170]

Please rebase

[ohagendorf]

It's rebased.

I'll check the ARM lib problem later again to describe it in an issue.

[ohagendorf]

Maybe using the default_toolchain option in targets.json would ease the configuration:

        try:
            if TARGET_MAP[self.target].progen['uvision5']['template']:
                tool_specific['uvision5'] = TARGET_MAP[self.target].progen['uvision5']
        except KeyError:
            # use default template
            # by the mbed projects
            if TARGET_MAP[self.target].default_toolchain == 'uARM':
                tool_specific['uvision5'] = {
                        'template': [join(dirname(__file__),  'uvision_microlib.uvproj.tmpl')],
                }
            else:
                tool_specific['uvision5'] = {
                        'template': [join(dirname(__file__),  'uvision.uvproj.tmpl')],
                }

With this we wouldn't need any prog_gen option for Keil5 in targets.json except for a non default functionality e.g. for the NUCLEO_F042 which needs a specific uvision template.

[0xc0170]

With this we wouldn't need any prog_gen option for Keil5 in targets.json except for a non default functionality e.g. for the NUCLEO_F042 which needs a specific uvision template.

Yes that would be better ! but with recent flags consolidation, I believe microlib is set by default via misc options, and template is not needed anymore, worth trying. I haven't got time to test this, but uARM targets add --microlib + one define to the flags, thus should be active.

[0xc0170]

looks fine to me, as stated in the first message, targets >=64k flash should use ARM and fix those targets

cc @bcostm

[bcostm]

targets >=64k flash should use ARM

Yes, this was already raised in Issue #1536 but nothing has been clearly decided.

If we do this it will solve the RTOS+InterruptIn Issue #1737

cc @screamerbg

[0xc0170]

Sorry for causing the conflicts in this PR, we merged the microlib template cleanup, can you rebase on top of master? To apply only the new template you are introducing?

[ohagendorf]

No problem.
I've done it: only some default_toolchain entries and the NUCLEO_F042 staff is remaining

[0xc0170]

Thanks for the rebase. It's fine to add that cross optimization, however I would wonder why this special flag is required. It's not used by scripts (it's project thing), will an app fit then?

To the uARM option, this does not solve the real issue with ARM. I would not change the default toolchain for those F4/F7 to uARM , not only size but also the thread safety, as there were latest changes, for uARM you can use just one thread.

scatter file for ARM is not correct

Is this issue created and tracked? @bcostm @adustm Can you have a look? If this can get fixed, this PR would remove that uARM changes.

[ohagendorf]

I think the scatter file problem was my own failure. I had it several times but can't reproduce it any longer since a couple of days. And I don't know what it was.

When the cross optimization flag is set the ide will compile and link several times to optimize the binary size. In this case it builds the app three times. Without the flag we got an binary size error. I used only the project.py export to uvision5.

One of our PhD students and I, we had this problem since several months. But when I'm checking it now, everything is OK: when building with build.py/make.py and also when exporting with project.py.

Maybe the huge amount of changes during the last weeks after my first PR solved the size problem.

I introduced uARM as default toolchain because with ARM toolchain the projects didn't run. That is already solved for the F7xx targets in PR #1909 I'm not sure if it is solved also for F4xx targets but currently all F4xx targets use uARM. In PR #1909 the toolchain is set to ARM.

But nevertheless all NUCLEO and DISCO entries in target.json have an default_toolchain option except both F7 and the DISCO_F407 target.

So it seems that only the default toolchain for DISCO_F407 is remaining usefull in this PR. Everything else is gone away.

[0xc0170]

Some good news, will you rebase it then ? If you find the issues with ARM, please create a new issue. we rather fix it than changing the toolchain. uARM can be used as it's supported but not in the online IDE by default for those "huge" targets

[ohagendorf]

I didn't rebased but removed everything except the DISCO_F407 default_toolchain. Rebasing seems not necessary.

I'll check the uARM/ARM problem with F4xx targets and submit an issue when necessary.

[0xc0170]

What's wrong with DISCO_F407VG and ARM? sorry for having so many questions

[ohagendorf]

I used uARM because all F4 targets use uARM. And several weeks ago projects with ARM didn't run when using a stdio printf.
I just tested the DISCO_F407 and the ARM toolchain looks good. I did the same with NUCLEO_F446 and got also nearly perfect results. I can run the tests with the other F4 targets and submit a PR with changes of the default_toolchain from uARM to ARM.

Result	Target	Toolchain	Test ID	Test Description	Elapsed Time (sec)	Timeout (sec)	Loops
OK	DISCO_F407VG	uARM	DTCT_1	Simple detect test	0.48	10	1/1
OK	DISCO_F407VG	uARM	EXAMPLE_1	/dev/null	3.45	20	1/1
OK	DISCO_F407VG	uARM	MBED_10	Hello World	0.35	5	1/1
OK	DISCO_F407VG	uARM	MBED_11	Ticker Int	11.37	15	1/1
OK	DISCO_F407VG	uARM	MBED_12	C			1.37
FAIL	DISCO_F407VG	uARM	MBED_16	RTC	10.34	20	0/1
OK	DISCO_F407VG	uARM	MBED_2	stdio	0.75	20	1/1
OK	DISCO_F407VG	uARM	MBED_23	Ticker Int us	11.37	15	1/1
OK	DISCO_F407VG	uARM	MBED_24	Timeout Int us	11.41	15	1/1
OK	DISCO_F407VG	uARM	MBED_25	Time us	11.39	15	1/1
OK	DISCO_F407VG	uARM	MBED_26	Integer constant division	1.39	20	1/1
OK	DISCO_F407VG	uARM	MBED_34	Ticker Two callbacks	11.37	15	1/1
OK	DISCO_F407VG	uARM	MBED_37	Serial NC RX	11.94	20	1/1
OK	DISCO_F407VG	uARM	MBED_38	Serial NC TX	10.89	20	1/1
FAIL	DISCO_F407VG	uARM	MBED_39	Serial Complete	5.38	20	0/1
OK	DISCO_F407VG	uARM	MBED_A1	Basic	1.36	20	1/1
OK	DISCO_F407VG	uARM	MBED_A21	Call function before main (mbed_main)	1.42	20	1/1
OK	DISCO_F407VG	uARM	MBED_A9	Serial Echo at 115200	6.51	20	1/1
OK	DISCO_F407VG	uARM	MBED_BUSOUT	BusOut	2.27	15	1/1
TIMEOUT	DISCO_F407VG	uARM	RTOS_1	Basic thread	30.25	15	0/1
TIMEOUT	DISCO_F407VG	uARM	RTOS_2	Mutex resource lock	40.26	20	0/1
TIMEOUT	DISCO_F407VG	uARM	RTOS_3	Semaphore resource lock	40.27	20	0/1
TIMEOUT	DISCO_F407VG	uARM	RTOS_4	Signals messaging	20.25	10	0/1
TIMEOUT	DISCO_F407VG	uARM	RTOS_5	Queue messaging	20.24	10	0/1
TIMEOUT	DISCO_F407VG	uARM	RTOS_6	Mail messaging	20.25	10	0/1
TIMEOUT	DISCO_F407VG	uARM	RTOS_7	Timer	30.26	15	0/1
TIMEOUT	DISCO_F407VG	uARM	RTOS_8	ISR (Queue)	20.24	10	0/1
OK	DISCO_F407VG	ARM	DTCT_1	Simple detect test	0.48	10	1/1
OK	DISCO_F407VG	ARM	EXAMPLE_1	/dev/null	3.41	20	1/1
OK	DISCO_F407VG	ARM	MBED_10	Hello World	0.38	5	1/1
OK	DISCO_F407VG	ARM	MBED_11	Ticker Int	11.38	15	1/1
OK	DISCO_F407VG	ARM	MBED_12	C			1.38
FAIL	DISCO_F407VG	ARM	MBED_16	RTC	26.01	20	0/1
OK	DISCO_F407VG	ARM	MBED_2	stdio	0.78	20	1/1
OK	DISCO_F407VG	ARM	MBED_23	Ticker Int us	11.39	15	1/1
OK	DISCO_F407VG	ARM	MBED_24	Timeout Int us	11.42	15	1/1
OK	DISCO_F407VG	ARM	MBED_25	Time us	11.38	15	1/1
OK	DISCO_F407VG	ARM	MBED_26	Integer constant division	1.39	20	1/1
OK	DISCO_F407VG	ARM	MBED_34	Ticker Two callbacks	11.37	15	1/1
OK	DISCO_F407VG	ARM	MBED_37	Serial NC RX	11.93	20	1/1
OK	DISCO_F407VG	ARM	MBED_38	Serial NC TX	10.89	20	1/1
FAIL	DISCO_F407VG	ARM	MBED_39	Serial Complete	5.39	20	0/1
OK	DISCO_F407VG	ARM	MBED_A1	Basic	1.33	20	1/1
OK	DISCO_F407VG	ARM	MBED_A21	Call function before main (mbed_main)	1.42	20	1/1
OK	DISCO_F407VG	ARM	MBED_A9	Serial Echo at 115200	6.54	20	1/1
OK	DISCO_F407VG	ARM	MBED_BUSOUT	BusOut	2.27	15	1/1
TIMEOUT	DISCO_F407VG	ARM	RTOS_1	Basic thread	30.28	15	0/1
TIMEOUT	DISCO_F407VG	ARM	RTOS_2	Mutex resource lock	40.27	20	0/1
TIMEOUT	DISCO_F407VG	ARM	RTOS_3	Semaphore resource lock	40.27	20	0/1
TIMEOUT	DISCO_F407VG	ARM	RTOS_4	Signals messaging	20.25	10	0/1
TIMEOUT	DISCO_F407VG	ARM	RTOS_5	Queue messaging	20.25	10	0/1
TIMEOUT	DISCO_F407VG	ARM	RTOS_6	Mail messaging	20.28	10	0/1
TIMEOUT	DISCO_F407VG	ARM	RTOS_7	Timer	30.26	15	0/1
TIMEOUT	DISCO_F407VG	ARM	RTOS_8	ISR (Queue)	20.24	10	0/1

[0xc0170]

Thanks ! we can close this as by default , ARM is set. Feel free to close this, and submit patches for ARM