Support GCC

[Timmmm]

It would be nice if you didn't have to spend thousands on a Keil license to compile this!

[kylemanna]

Additional gcc discussion at #110

[c1728p9]

Before GCC support can be added RTX needs to be updated. The version of RTX used by DAPLink doesn't have support for GCC, but newer versions do.

[flit]

Does the USB stack already support gcc?

[c1728p9]

I don't think the USB stack has strong ties to any toolchain, so it should be fairly straight forward to update to use GCC.

[OwenBrotherwood]

Can we track who has the knowledge and who has the time to obtain a basic "this is as far as I/we got" to facilitate PR's for doc and possible forks to show their results be they ever so humble with possible PR's to code with possible problems not solved at the moment.

[OwenBrotherwood]

@c1728p9 named RTX.
This is probably http://www2.keil.com/mdk5/cmsis/rtx/

Royalty-Free - No on-going costs.
There are no run-time royalty payments or other hidden charges. Ship your RTX based products without further fees or recurring costs

Given no cost, and if the RTX refered to is the one I found, the github seems to be a start for compiling?
https://github.com/ARM-software/CMSIS_5

---

Additional links found
http://www.keil.com/pack/doc/CMSIS/RTOS/html/index.html

[c1728p9]

Hi @OwenBrotherwood, yep that is the right RTX. Since it's open source anyone who is interested could start the porting process.

[OwenBrotherwood]

In order to create a form for "if someone suddenly does not have the time", the problem needs to be broken up into blocks that are describable as start/finish such that one can build up to the final result
Anyone have a breakdown on the blocks required?

[OwenBrotherwood]

It would seem that the correct branch is this for micro:bit
https://github.com/mbedmicro/DAPLink/tree/freescale

[jaustin]

Actually @OwenBrotherwood this is the right place for micro:bit https://github.com/mbedmicro/DAPLink/tree/microbit-0234 (that's the schools drop) and https://github.com/mbedmicro/DAPLink/tree/v0241 (the base that Farnell used for the newer firmware)

[OwenBrotherwood]

So many micro:bits out there and so many people wanting to do cool things with them.
We need open-source compilation.

[OwenBrotherwood]

Dunno if this merge of code gives anyone any ideas.
https://github.com/OwenBrotherwood/DAPLink/tree/freescale-i-sys

I haven't gone thru the code to see if it needs Kiel

---

Note:
Purely a mechanical operation of google after how to merge one repro onto a branch of another with only one hairy moment
https://github.com/OwenBrotherwood/DAPLink/tree/freescale
https://github.com/OwenBrotherwood/DAPLink/tree/CMSIS-DAP_IDAP-Link

C:\source\repos\github\OwenBrotherwood\DAPLink>git merge CMSIS-DAP_IDAP-Link
Auto-merging source/common/hal/nxp/lpc11u35/DAP_config.h
CONFLICT (modify/delete): interface/mdk/lpc11u35/lpc11u35_interface.uvproj deleted in HEAD and
modified in CMSIS-DAP_IDAP-Link. Version CMSIS-DAP_IDAP-Link of interface/mdk/lpc11u35/lpc11u35
_interface.uvproj left in tree.
Automatic merge failed; fix conflicts and then commit the result.
error: addinfo_cache failed for path 'source/common/hal/nxp/lpc11u35/DAP_config.h'

C:\source\repos\github\OwenBrotherwood\DAPLink>git mergetool

This message is displayed because 'merge.tool' is not configured.
See 'git mergetool --tool-help' or 'git help config' for more details.
'git mergetool' will now attempt to use one of the following tools:
tortoisemerge emerge vimdiff
Merging:
interface/mdk/lpc11u35/lpc11u35_interface.uvproj

Deleted merge conflict for 'interface/mdk/lpc11u35/lpc11u35_interface.uvproj':
  {local}: deleted
  {remote}: modified file
Use (m)odified or (d)eleted file, or (a)bort? m

[flit]

@OwenBrotherwood I'm afraid that branch is so far out of date that it's not much help.

https://github.com/OwenBrotherwood/DAPLink/tree/freescale is a very old DAPLink version, right after the folder structure started being reorganized.
https://github.com/OwenBrotherwood/DAPLink/tree/CMSIS-DAP_IDAP-Link is the pre-DAPLink "mbed CMSIS-DAP" project that uses an entirely different folder layout and doesn't use progen.

Neither source branch supported gcc. (Unless I missed something.)

[OwenBrotherwood]

yep: afraid it was so.
I just merged in hope and not so much in outright conviction that it would give anything.

At least I learned some more git techniques: I am not a programmer in my day time job (and sometimes it shows :) )

---

And of course, it doesn't do too much harm to give the issue a bump every now and then.

"Everybody is talking about apathy, but nobody is doing anything about it" :)

[Awais174]

Hey, I created eclipse_gcc_arm project and got following error:

11:12:37 **** Incremental Build of configuration Default for project stm32f103xb_nucleo_f103rb_if ****
make all
mkdir build
mkdir: cannot create directory `build': File exists
Makefile:135: recipe for target 'create_outputdir' failed
make: [create_outputdir] Error 1 (ignored)
make: *** No rule to make target '[]', needed by 'build/stm32f103xb_nucleo_f103rb_if.elf'. Stop.

Is it because the generated makefile does not reference to LD script?

I am trying to understand how much work is needed to enable GCC ARM build; I will be grateful for the feedback.

[GenericWorkName]

Any news?

[vaughanatworld]

Just like everyone else, I wish to compile a DAPlink with gcc (open software disciple)
I've done a search for a gcc ported RTX and have found nothing.
I've done a search for port of DAPlink to CMSIS-rtos. Nothing.
I suspect folks are frustrated by the amount of work to do the conversion (armcc to gcc), comply with progen (multiple development environments) and unit testing (multiple MPUs).
Individual initiatives are not being incorporated back into the master github. The work becomes dated and is divergent.
The result is the adoption of DAPLink is being blunted.

To me, to fix this situation, some of the necessary (not sufficient) conditions are:

• to make the code base independent of MDK ARMCC dependencies (support at least gcc, and perhaps clang ).
• to modify the code to support the CMSIS-rtos interface and free the design from just one rtos. ( allow RTX, freertos, others).
• expand github to capture individual contributions and distribute testing to those who have different development and MPU environments. This means project management at some level (time and $).

comments?

[cederom]

DAPLink is created, developed and maintained by ARM MBED Team. They control management, architecture, internals, design and documentation. There are some good news you may want to read at #482 :-)

As stated by @flit:

This is the official story: The limitation of currently requiring Keil MDK to build DAPLink has nothing to do with tool quality. It is simply due to the fact that some of the libraries that are used in DAPLink (USB, RTX RTOS) come from Keil middleware and are written in so that they only build with armcc v5. Porting these libraries to other compilers (we need to support all of armcc v5, armcc v6, gcc, and IAR) is infeasible.

However, we recognise that this limitation is a serious issue affecting the usability of DAPLink by the community. And, we are actively working on a solution. Because of the above mentioned problem, the solution will require switching to new a USB library, and moving to RTX5 (CMSIS-RTOS2) that already supports all 4 toolchains. The goal is to have the new solution in place by early Q1 2019, or earlier if possible.

[vaughanatworld]

Thank you for the response. Good news.
...and I'm not completely crazy,
I'll just use stlink and j-link for now.

[cederom]

But DAPLink works fine already on a wide range of boards, targets and interfaces.. I use it everyday with no problem.. its far more effective than old tools that I have used or even created myself years ago..

What keeps you away from current DAPLink and what would GCC really solve for you @vaughanatworld ?

[therealprof]

@cederom For me this question is really easy to answer: The available to build it myself and contribute and thus integrate one in my own circuits. At the moment it's more of a use it on the micro:bit and get a "FRDM board just to drive foreign MCUs" kind of affair...

[cederom]

Sure thing! Looks like it should be here quite soon.. I am waiting for that too :-)

[Novakov]

I see that this issue is still in backlog and we are well into Q1 2019 :) Is there any plan/roadmap for this issue? I would like to run DAPLink on not supported yet platform but Keil requirement is showstopper for me.

[cederom]

+1 :-)

[flit]

We are actually making progress towards this goal. The first step was to move to mbed-cli for building DAPLink. This has been accomplished. Right now we're actively working on switching the RTOS, but are having size problems with RTX5 and the bootloader. I'll work on creating some issues and linking them to this one so that the progress is more clear.

[Novakov]

Great news! Thanks for linking issues here.

[eddie0x7c3]

Everything was going well until I hit the compile button on Keil and got the "linker" size limit error lol. I have tried the mBed CLI but I keep getting errors about missing json files. I might give it a shot again. Since Since Keil basically belongs to ARM cant they just do like a conditional license where you can just remove the restrictions of the free version to compile DapLink... Isnt Keil professional free to use for Stm32G0/L0/F0 cant Dap run on those? and thus Keil allow us to compile it?

[Terstegge]

Any news regarding this topic? I would be very interested in porting DapLink to some microcontroller boards which not yet support DapLink. And I definitely need GCC for that ...

[rbarzic]

Any news regarding this topic? I would be very interested in porting DapLink to some microcontroller boards which not yet support DapLink. And I definitely need GCC for that ...

Not to mention the impossibility to build it on Linux without proprietary tools , because it requires either Keil or ARM Compiler (which is provided free by Mbed Studio, which is not available on Linux...). Supporting GCC will just solve this issue

[0xc0170]

There is currently no immediate plan to complete the referenced tasks above (RTX5, USB stack - main dependencies on ARMC5).

Switching to RTX5 should not be difficult with the latest changes - my assumption, will need to study further the latest code base here (appreciate any help here, PR welcome).
USB stack on the other hand might be more difficult.

[flit]

Update: The port to gcc is almost complete. I just decided to bite the bullet and do it. 😁

It's currently on my feature/gcc branch. Everything except the Musca-B1 boards builds (their .text is currently too large). Only builds using the k20dx HIC are known to work right now.

Below is the only documentation right now. If you don't understand any steps, please wait until the real documentation is ready.

How to build

Requires project-generator from the dev_v0.10 branch to be installed in your virtualenv.

Commands are to be run from DAPLink root.

1. mbed deploy
   • This loads the mbed-os directory for RTX5. (RTX5 sources will almost certainly be moved into DAPLink repo, and mbed-cli building support removed.)
2. progen build -t make_gcc_arm -j8 [-p <project-name>]

Or use:

2. progen generate -t make_gcc_arm [-p <project-name>]
   • Makefiles appear under projectfiles/make_gcc_arm/*/
3. make -C projectfiles/make_gcc_arm/<project-name> -j8

The progen eclipse_make_gcc_arm tool also works so you can use GNU MCU Eclipse to build and debug (with pyOCD, of course!). Just import the projects under projectfiles/eclipse_make_gcc_arm/.

If you test and run into problems prior to gcc support being finalized, please create issues and (preferrably) PRs on my fork and not this upstream repo.

[balanceTWK]

Update: The port to gcc is almost complete. I just decided to bite the bullet and do it. 😁

It's currently on my feature/gcc branch. Everything except the Musca-B1 boards builds (their .text is currently too large). Only builds using the k20dx HIC are known to work right now.

Below is the only documentation right now. If you don't understand any steps, please wait until the real documentation is ready.

How to build

Requires project-generator from the dev_v0.10 branch to be installed in your virtualenv.

Commands are to be run from DAPLink root.

1. mbed deploy

   • This loads the mbed-os directory for RTX5. (RTX5 sources will almost certainly be moved into DAPLink repo, and mbed-cli building support removed.)

2. progen build -t make_gcc_arm -j8 [-p <project-name>]

Or use:

1. progen generate -t make_gcc_arm [-p <project-name>]

   • Makefiles appear under projectfiles/make_gcc_arm/*/

2. make -C projectfiles/make_gcc_arm/<project-name> -j8

The progen eclipse_make_gcc_arm tool also works so you can use GNU MCU Eclipse to build and debug (with pyOCD, of course!). Just import the projects under projectfiles/eclipse_make_gcc_arm/.

If you test and run into problems prior to gcc support being finalized, please create issues and (preferrably) PRs on my fork and not this upstream repo.

Great, I will try to transplant it to my project.😀

[borneoa]

The build for stm32f103xb are successfully, but then the FW doesn't work.
I programmed the bootloader stm32f103xb_bl.bin through SWD and it starts correctly, showing MAINTENANCE folder.
But then any tentative to load a DAPLink FW fails, either immediately after copy it in the folder or halts with red LED and fail at USB re-plug. In all case it returns in MAINTEINANCE after LED flashes fast.
I'm using a Linux PC either for building and for flashing.
Any suggestion on how to proceed?
Since you mention "Only builds using the k20dx HIC are known to work right now", does it make sense I open a ticket?

[eleenest]

Hello,
I wanted check the status of this issue.
We are interested in being able to run daplink on a STM32 (newer part, like STM32H743).
If I understand correctly this issue ( and 580 / 581 ) would be part of that (to compile in another IDE on mac / linux).

We are thinking of helping with these items (as an intern project this summer).

What setup would be needed to start on this?
Is it a windows PC with Keil tools?

Thanks,
Eric

[ffjunq]

Hello, I would like to know the status of this threat.

I have a project running and working using the ARM compiler, however, Keil's 1 month free linenship is over and I would like to know if I can migrate to GCC.

I use STM32F103 as HIC and LPC1857 as target.

Can anybody help me? What is the problem today when trying to compile DAPLink for HIC STM32F103?

Thank you very much for your attention!

[0Grit]

Can't wait

[flit]

@ffjunq Sorry I didn't see your comment! The work has picked back up (finally have time now that I'm on vacation for the holidays). It's currently being done on my feature/gcc branch (based on a few other branches to break the work into more mergeable chunks). We're planning to move this branch to this (upstream) repo soon so it's more visible.

We need someone to test the STM32F103 port! If you could help, that would be great!

Anyone that can help test the gcc port on any HIC would be greatly appreciated.

[cederom]

I have some boards will be happy to test builds and runs on FreeBSD :-)

[ffjunq]

Many thanks for the reply. I have some cards here, I can dedicate some time to help with tests, especially if it involves the micro STM32F072. Update me with whatever you need! Em sáb., 12 de dez. de 2020 às 18:54, Tomasz CEDRO <notifications@github.com> escreveu:

…

I have some boards will be happy to test builds and runs on FreeBSD :-) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#197 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQT6FZAIXLA7FLYBPVLZHPTSUPRAVANCNFSM4CYA3RZA> .

[0Grit]

I can assist with cypress based targets next year if timing aligns. The HIC will not however be cypress based. 😉

[mbrossard]

Hi everyone, I just wanted to draw your attention to #750.

Note:

• I have only tested the make_gcc_arm toolchain option (well there is also CMake with Add support for CMake for GCC / ARMCC / ARMCLANG project-generator/project_generator#475)
• mbed deploy is not needed

$ progen generate -t make_gcc_arm -p <project-name>
$ make -C projectfiles/make_gcc_arm/<project-name>

[robschw]

I a new in develop with MAKE! (I use only IDEs)
Please could you give me some information to install “MAKE” for Windows10 in easy way?

[mbrossard]

Fixed in v0257

[cederom]

MISSION ACCOMPLISHED! 😎