Reply by Mike Perkins ●September 1, 20172017-09-01
On 01/09/2017 03:16, lasselangwadtchristensen@gmail.com wrote:

> Den onsdag den 30. august 2017 kl. 05.47.40 UTC+2 skrev Mike Perkins:
>> On 30/08/2017 03:44, Mike Perkins wrote:
>>> On 29/08/2017 20:56, Mike Perkins wrote:
>>>> On 28/08/2017 22:45, Dave Nadler wrote:
>>>>> On Monday, August 28, 2017 at 5:24:23 PM UTC-4, Mike Perkins wrote:
>>>>>> Is there a blow by blow account of how to install this with either Neon
>>>>>> or Oxygen, or should I bit the bullet and use an IDE already put
>>>>>> together.
>>>>>
>>>>> Try:
>>>>> https://mcuoneclipse.com/2017/07/30/breathing-with-oxygen-diy-arm-cortex-m-cc-ide-and-toolchain-with-eclipse-oxygen/
>>>>>
>>>>>
>>>>>
>>>>> Hope that helps!
>>>>> Best Regards, Dave
>>>>>
>>>>> PS: Let us know how it goes...
>>>>
>>>> Thank you muchly.
>>>>
>>>> One big point is I didn't realise I could install from local archives.
>>>>
>>>> As per article I did look at upgrading the ST-Link V2 to the Segger
>>>> firmware but on further investigation that's not possible, only on the
>>>> Discovery boards.
>>>> Indeed if I try as per:
>>>>
>>>> https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/
>>>>
>>>>
>>>> I get:
>>>>   Identifying ST-LINK variant...ERROR: Unsupported ST-LINK hardware
>>>> variant
>>>>
>>>> However I did upgrade the ST-Link V2 firmware to V2.J28.S7 and using the
>>>> driver 2.0.0
>>>>
>>>> I can build fine, using a 'New' test example of 'Blinky'.
>>>>
>>>> However, despite making sure OpenOCD is in the correct path, I get a
>>>> time-out when trying to debug after:
>>>>
>>>> Debug: 368 313 command.c:143 script_debug(): command - ocd_command
>>>> ocd_command type ocd_mflash init
>>>> Debug: 369 313 command.c:143 script_debug(): command - ocd_mflash
>>>> ocd_mflash init
>>>> Debug: 371 313 mflash.c:1377 handle_mflash_init_command(): Initializing
>>>> mflash devices...
>>>> Debug: 372 313 command.c:143 script_debug(): command - ocd_command
>>>> ocd_command type ocd_nand init
>>>> Debug: 373 313 command.c:143 script_debug(): command - ocd_nand ocd_nand
>>>> init
>>>> Debug: 375 313 tcl.c:497 handle_nand_init_command(): Initializing NAND
>>>> devices...
>>>> Debug: 376 313 command.c:143 script_debug(): command - ocd_command
>>>> ocd_command type ocd_pld init
>>>> Debug: 377 313 command.c:143 script_debug(): command - ocd_pld ocd_pld
>>>> init
>>>> Debug: 379 334 pld.c:205 handle_pld_init_command(): Initializing PLDs...
>>>> Info : 380 334 server.c:312 add_service(): Listening on port 3333 for
>>>> gdb connections
>>>>
>>>> I'm using
>>>>   -f interface/stlink-v2.cfg  -f target/stm32f1x.cfg -d3 -l openocd.log
>>>> in the config options.
>>>>
>>>> It seems to listen but gets nothing, yet the ARM tools including
>>>> arm-none-eabi-gdb.exe are in the right path or the project wouldn't
>>>> build.
>>>
>>> Finally got it going in a VM. The issue is to have the full GDB
>>> executable in the GDB Client Setup. I had believed, very wrongly, that
>>> the GNU ARM tool folder would be sufficient, it isn't!
>>>
>>> I'm now in a position to update plugins as and when required. Many
>>> thanks for that link, its made things a whole lot more repeatable. It
>>> should also be portable as I'm using ${eclipse_home} to indicate the
>>> eclipse home directory.
>>>
>>> With 'Blinky program on an old Olimex board I can get "Hello ARM World"
>>> and get the LED to flash.
>>>
>>> Thanks.
>>
>> One more thing, I have found all the versions of OpenOCD 0.10.0
>> unreliable. I go from working to not working with:
>>    undefined debug reason 7 - target needs reset
>>    Remote failure reply: E0E
>>
>> or
>>    Error in final launch sequence
>>    Failed to execute MI command:
>>    -target-select remote localhost:3333
>>    Error message from debugger back end:
>>    Remote failure reply: E0E
>>    Failed to execute MI command:
>>    -target-select remote localhost:3333
>>    Error message from debugger back end:
>>    Remote failure reply: E0E
>>    Remote failure reply: E0E
>>
>> It seems a known bug, so now using 0.9.0 (GNU ARM Eclipse OpenOCD
>> v0.9.0-20150519*) Unfortunately it only comes in an executable, though
>> can be 'unzipped' by 7zip. So far so good.
>
> everything work out of the box with http://www.openstm32.org


Now you tell me!!!

Thanks for the link, I'll be adding it to my bookmarks!
Reply by ●August 31, 20172017-08-31
Den onsdag den 30. august 2017 kl. 05.47.40 UTC+2 skrev Mike Perkins:

> On 30/08/2017 03:44, Mike Perkins wrote:
> > On 29/08/2017 20:56, Mike Perkins wrote:
> >> On 28/08/2017 22:45, Dave Nadler wrote:
> >>> On Monday, August 28, 2017 at 5:24:23 PM UTC-4, Mike Perkins wrote:
> >>>> Is there a blow by blow account of how to install this with either Neon
> >>>> or Oxygen, or should I bit the bullet and use an IDE already put
> >>>> together.
> >>>
> >>> Try:
> >>> https://mcuoneclipse.com/2017/07/30/breathing-with-oxygen-diy-arm-cortex-m-cc-ide-and-toolchain-with-eclipse-oxygen/
> >>>
> >>>
> >>>
> >>> Hope that helps!
> >>> Best Regards, Dave
> >>>
> >>> PS: Let us know how it goes...
> >>
> >> Thank you muchly.
> >>
> >> One big point is I didn't realise I could install from local archives.
> >>
> >> As per article I did look at upgrading the ST-Link V2 to the Segger
> >> firmware but on further investigation that's not possible, only on the
> >> Discovery boards.
> >> Indeed if I try as per:
> >>
> >> https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/
> >>
> >>
> >> I get:
> >>   Identifying ST-LINK variant...ERROR: Unsupported ST-LINK hardware
> >> variant
> >>
> >> However I did upgrade the ST-Link V2 firmware to V2.J28.S7 and using the
> >> driver 2.0.0
> >>
> >> I can build fine, using a 'New' test example of 'Blinky'.
> >>
> >> However, despite making sure OpenOCD is in the correct path, I get a
> >> time-out when trying to debug after:
> >>
> >> Debug: 368 313 command.c:143 script_debug(): command - ocd_command
> >> ocd_command type ocd_mflash init
> >> Debug: 369 313 command.c:143 script_debug(): command - ocd_mflash
> >> ocd_mflash init
> >> Debug: 371 313 mflash.c:1377 handle_mflash_init_command(): Initializing
> >> mflash devices...
> >> Debug: 372 313 command.c:143 script_debug(): command - ocd_command
> >> ocd_command type ocd_nand init
> >> Debug: 373 313 command.c:143 script_debug(): command - ocd_nand ocd_nand
> >> init
> >> Debug: 375 313 tcl.c:497 handle_nand_init_command(): Initializing NAND
> >> devices...
> >> Debug: 376 313 command.c:143 script_debug(): command - ocd_command
> >> ocd_command type ocd_pld init
> >> Debug: 377 313 command.c:143 script_debug(): command - ocd_pld ocd_pld
> >> init
> >> Debug: 379 334 pld.c:205 handle_pld_init_command(): Initializing PLDs...
> >> Info : 380 334 server.c:312 add_service(): Listening on port 3333 for
> >> gdb connections
> >>
> >> I'm using
> >>   -f interface/stlink-v2.cfg  -f target/stm32f1x.cfg -d3 -l openocd.log
> >> in the config options.
> >>
> >> It seems to listen but gets nothing, yet the ARM tools including
> >> arm-none-eabi-gdb.exe are in the right path or the project wouldn't
> >> build.
> >
> > Finally got it going in a VM. The issue is to have the full GDB
> > executable in the GDB Client Setup. I had believed, very wrongly, that
> > the GNU ARM tool folder would be sufficient, it isn't!
> >
> > I'm now in a position to update plugins as and when required. Many
> > thanks for that link, its made things a whole lot more repeatable. It
> > should also be portable as I'm using ${eclipse_home} to indicate the
> > eclipse home directory.
> >
> > With 'Blinky program on an old Olimex board I can get "Hello ARM World"
> > and get the LED to flash.
> >
> > Thanks.
> 
> One more thing, I have found all the versions of OpenOCD 0.10.0 
> unreliable. I go from working to not working with:
>    undefined debug reason 7 - target needs reset
>    Remote failure reply: E0E
> 
> or
>    Error in final launch sequence
>    Failed to execute MI command:
>    -target-select remote localhost:3333
>    Error message from debugger back end:
>    Remote failure reply: E0E
>    Failed to execute MI command:
>    -target-select remote localhost:3333
>    Error message from debugger back end:
>    Remote failure reply: E0E
>    Remote failure reply: E0E
> 
> It seems a known bug, so now using 0.9.0 (GNU ARM Eclipse OpenOCD 
> v0.9.0-20150519*) Unfortunately it only comes in an executable, though 
> can be 'unzipped' by 7zip. So far so good.


everything work out of the box with http://www.openstm32.org
Reply by Mike Perkins ●August 30, 20172017-08-30
On 30/08/2017 03:44, Mike Perkins wrote:

> On 29/08/2017 20:56, Mike Perkins wrote:
>> On 28/08/2017 22:45, Dave Nadler wrote:
>>> On Monday, August 28, 2017 at 5:24:23 PM UTC-4, Mike Perkins wrote:
>>>> Is there a blow by blow account of how to install this with either Neon
>>>> or Oxygen, or should I bit the bullet and use an IDE already put
>>>> together.
>>>
>>> Try:
>>> https://mcuoneclipse.com/2017/07/30/breathing-with-oxygen-diy-arm-cortex-m-cc-ide-and-toolchain-with-eclipse-oxygen/
>>>
>>>
>>>
>>> Hope that helps!
>>> Best Regards, Dave
>>>
>>> PS: Let us know how it goes...
>>
>> Thank you muchly.
>>
>> One big point is I didn't realise I could install from local archives.
>>
>> As per article I did look at upgrading the ST-Link V2 to the Segger
>> firmware but on further investigation that's not possible, only on the
>> Discovery boards.
>> Indeed if I try as per:
>>
>> https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/
>>
>>
>> I get:
>>   Identifying ST-LINK variant...ERROR: Unsupported ST-LINK hardware
>> variant
>>
>> However I did upgrade the ST-Link V2 firmware to V2.J28.S7 and using the
>> driver 2.0.0
>>
>> I can build fine, using a 'New' test example of 'Blinky'.
>>
>> However, despite making sure OpenOCD is in the correct path, I get a
>> time-out when trying to debug after:
>>
>> Debug: 368 313 command.c:143 script_debug(): command - ocd_command
>> ocd_command type ocd_mflash init
>> Debug: 369 313 command.c:143 script_debug(): command - ocd_mflash
>> ocd_mflash init
>> Debug: 371 313 mflash.c:1377 handle_mflash_init_command(): Initializing
>> mflash devices...
>> Debug: 372 313 command.c:143 script_debug(): command - ocd_command
>> ocd_command type ocd_nand init
>> Debug: 373 313 command.c:143 script_debug(): command - ocd_nand ocd_nand
>> init
>> Debug: 375 313 tcl.c:497 handle_nand_init_command(): Initializing NAND
>> devices...
>> Debug: 376 313 command.c:143 script_debug(): command - ocd_command
>> ocd_command type ocd_pld init
>> Debug: 377 313 command.c:143 script_debug(): command - ocd_pld ocd_pld
>> init
>> Debug: 379 334 pld.c:205 handle_pld_init_command(): Initializing PLDs...
>> Info : 380 334 server.c:312 add_service(): Listening on port 3333 for
>> gdb connections
>>
>> I'm using
>>   -f interface/stlink-v2.cfg  -f target/stm32f1x.cfg -d3 -l openocd.log
>> in the config options.
>>
>> It seems to listen but gets nothing, yet the ARM tools including
>> arm-none-eabi-gdb.exe are in the right path or the project wouldn't
>> build.
>
> Finally got it going in a VM. The issue is to have the full GDB
> executable in the GDB Client Setup. I had believed, very wrongly, that
> the GNU ARM tool folder would be sufficient, it isn't!
>
> I'm now in a position to update plugins as and when required. Many
> thanks for that link, its made things a whole lot more repeatable. It
> should also be portable as I'm using ${eclipse_home} to indicate the
> eclipse home directory.
>
> With 'Blinky program on an old Olimex board I can get "Hello ARM World"
> and get the LED to flash.
>
> Thanks.


One more thing, I have found all the versions of OpenOCD 0.10.0 
unreliable. I go from working to not working with:
   undefined debug reason 7 - target needs reset
   Remote failure reply: E0E

or
   Error in final launch sequence
   Failed to execute MI command:
   -target-select remote localhost:3333
   Error message from debugger back end:
   Remote failure reply: E0E
   Failed to execute MI command:
   -target-select remote localhost:3333
   Error message from debugger back end:
   Remote failure reply: E0E
   Remote failure reply: E0E

It seems a known bug, so now using 0.9.0 (GNU ARM Eclipse OpenOCD 
v0.9.0-20150519*) Unfortunately it only comes in an executable, though 
can be 'unzipped' by 7zip. So far so good.
Reply by Mike Perkins ●August 29, 20172017-08-29
On 29/08/2017 20:56, Mike Perkins wrote:

> On 28/08/2017 22:45, Dave Nadler wrote:
>> On Monday, August 28, 2017 at 5:24:23 PM UTC-4, Mike Perkins wrote:
>>> Is there a blow by blow account of how to install this with either Neon
>>> or Oxygen, or should I bit the bullet and use an IDE already put
>>> together.
>>
>> Try:
>> https://mcuoneclipse.com/2017/07/30/breathing-with-oxygen-diy-arm-cortex-m-cc-ide-and-toolchain-with-eclipse-oxygen/
>>
>>
>> Hope that helps!
>> Best Regards, Dave
>>
>> PS: Let us know how it goes...
>
> Thank you muchly.
>
> One big point is I didn't realise I could install from local archives.
>
> As per article I did look at upgrading the ST-Link V2 to the Segger
> firmware but on further investigation that's not possible, only on the
> Discovery boards.
> Indeed if I try as per:
>
> https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/
>
> I get:
>   Identifying ST-LINK variant...ERROR: Unsupported ST-LINK hardware variant
>
> However I did upgrade the ST-Link V2 firmware to V2.J28.S7 and using the
> driver 2.0.0
>
> I can build fine, using a 'New' test example of 'Blinky'.
>
> However, despite making sure OpenOCD is in the correct path, I get a
> time-out when trying to debug after:
>
> Debug: 368 313 command.c:143 script_debug(): command - ocd_command
> ocd_command type ocd_mflash init
> Debug: 369 313 command.c:143 script_debug(): command - ocd_mflash
> ocd_mflash init
> Debug: 371 313 mflash.c:1377 handle_mflash_init_command(): Initializing
> mflash devices...
> Debug: 372 313 command.c:143 script_debug(): command - ocd_command
> ocd_command type ocd_nand init
> Debug: 373 313 command.c:143 script_debug(): command - ocd_nand ocd_nand
> init
> Debug: 375 313 tcl.c:497 handle_nand_init_command(): Initializing NAND
> devices...
> Debug: 376 313 command.c:143 script_debug(): command - ocd_command
> ocd_command type ocd_pld init
> Debug: 377 313 command.c:143 script_debug(): command - ocd_pld ocd_pld init
> Debug: 379 334 pld.c:205 handle_pld_init_command(): Initializing PLDs...
> Info : 380 334 server.c:312 add_service(): Listening on port 3333 for
> gdb connections
>
> I'm using
>   -f interface/stlink-v2.cfg  -f target/stm32f1x.cfg -d3 -l openocd.log
> in the config options.
>
> It seems to listen but gets nothing, yet the ARM tools including
> arm-none-eabi-gdb.exe are in the right path or the project wouldn't build.


Finally got it going in a VM. The issue is to have the full GDB 
executable in the GDB Client Setup. I had believed, very wrongly, that 
the GNU ARM tool folder would be sufficient, it isn't!

I'm now in a position to update plugins as and when required. Many 
thanks for that link, its made things a whole lot more repeatable. It 
should also be portable as I'm using ${eclipse_home} to indicate the 
eclipse home directory.

With 'Blinky program on an old Olimex board I can get "Hello ARM World" 
and get the LED to flash.

Thanks.
Reply by Mike Perkins ●August 29, 20172017-08-29
On 29/08/2017 21:10, Mike Perkins wrote:

> On 29/08/2017 07:30, Tilmann Reh wrote:
>> Mike Perkins schrieb:
>>
>>> Does anyone here have any suggestions? Yes I know of pay-for solutions
>>> but they're not ideal for multi-site solutions, plus the old system I
>>> had worked just as well as any pay IDE!
>>
>> You might have a look at Code::Blocks.
>> I like it very much.
>
> Thanks - it looks very interesting.


It appears an IDE, where you have to install plugins, much like eclipse. 
The only difference is say a plugin I would need is unobtanium. The 
Code::Blocks(STM32) net installer at:
   https://sourceforge.net/projects/codeblockeps-ni/
doesn't have a download area. Furthermore the 'installer' website
   http://epsdebugger.comsytec.com/
where the downloads are possibly subject to Euros10 is broken. All I get 
is spinning circles.
Reply by Mike Perkins ●August 29, 20172017-08-29
On 29/08/2017 07:30, Tilmann Reh wrote:

> Mike Perkins schrieb:
>
>> Does anyone here have any suggestions? Yes I know of pay-for solutions
>> but they're not ideal for multi-site solutions, plus the old system I
>> had worked just as well as any pay IDE!
>
> You might have a look at Code::Blocks.
> I like it very much.


Thanks - it looks very interesting.
Reply by Mike Perkins ●August 29, 20172017-08-29
On 29/08/2017 07:31, David Brown wrote:

> On 28/08/17 23:40, Mike Perkins wrote:
>> On 28/08/2017 22:36, John Speth wrote:
>>> On 8/28/2017 2:24 PM, Mike Perkins wrote:
>>>> A year or two ago I put together an IDE using eclipse, gnu arm tools,
>>>> openocd with a st link JTAG adaptor.
>>>>
>>>> I can't seem to get a working system together, and further more some
>>>> links aren't working I have used to install add-ins for Mars 2. Mars 2
>>>> was the system I know worked.
>>>>
>>>> Is there a blow by blow account of how to install this with either
>>>> Neon or Oxygen, or should I bit the bullet and use an IDE already put
>>>> together.
>>>>
>>>> Does anyone here have any suggestions? Yes I know of pay-for solutions
>>>> but they're not ideal for multi-site solutions, plus the old system I
>>>> had worked just as well as any pay IDE!
>>>
>>> You mean: Worked just as well ... , until it didn't work.
>>>
>>> Sorry for the negative reply but it sounds like now you're paying for
>>> the hidden cost of free.
>>
>> Yes, I'm aware of that, except some of the links whilst in 'Help>Install
>> software' no longer work. Perhaps its a weekend/holiday thing.
>>
>> Mind, I've know paid licensing issues cause as many nightmares!
>
> You haven't given much details of the problem here (not that I can be
> sure of giving helpful advice even if you had...).  It is possible that
> for some of the bits and pieces you have used, they have changed project
> location - moved from Sourceforge to Github, or whatever.  Personally, I
> usually try to avoid updating software like this.  I install an Eclipse
> build or other IDE in a directory, and leave it there - if I want a new
> version of the tools, I do it in a new directory with a separate
> installation.  I am particularly fussy about the key tools - the
> compiler and library - and never change these in a project.


I agree with you, and indeed I have learnt a few things from Dave in how 
you can install from archives.

In the past much has been downloaded from within eclipse, such its not 
always easy to keep track of what makes a working system.
Reply by Mike Perkins ●August 29, 20172017-08-29
On 28/08/2017 22:45, Dave Nadler wrote:

> On Monday, August 28, 2017 at 5:24:23 PM UTC-4, Mike Perkins wrote:
>> Is there a blow by blow account of how to install this with either Neon
>> or Oxygen, or should I bit the bullet and use an IDE already put together.
>
> Try: https://mcuoneclipse.com/2017/07/30/breathing-with-oxygen-diy-arm-cortex-m-cc-ide-and-toolchain-with-eclipse-oxygen/
>
> Hope that helps!
> Best Regards, Dave
>
> PS: Let us know how it goes...


Thank you muchly.

One big point is I didn't realise I could install from local archives.

As per article I did look at upgrading the ST-Link V2 to the Segger 
firmware but on further investigation that's not possible, only on the 
Discovery boards.
Indeed if I try as per:
 
https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/
I get:
   Identifying ST-LINK variant...ERROR: Unsupported ST-LINK hardware variant

However I did upgrade the ST-Link V2 firmware to V2.J28.S7 and using the 
driver 2.0.0

I can build fine, using a 'New' test example of 'Blinky'.

However, despite making sure OpenOCD is in the correct path, I get a 
time-out when trying to debug after:

Debug: 368 313 command.c:143 script_debug(): command - ocd_command 
ocd_command type ocd_mflash init
Debug: 369 313 command.c:143 script_debug(): command - ocd_mflash 
ocd_mflash init
Debug: 371 313 mflash.c:1377 handle_mflash_init_command(): Initializing 
mflash devices...
Debug: 372 313 command.c:143 script_debug(): command - ocd_command 
ocd_command type ocd_nand init
Debug: 373 313 command.c:143 script_debug(): command - ocd_nand ocd_nand 
init
Debug: 375 313 tcl.c:497 handle_nand_init_command(): Initializing NAND 
devices...
Debug: 376 313 command.c:143 script_debug(): command - ocd_command 
ocd_command type ocd_pld init
Debug: 377 313 command.c:143 script_debug(): command - ocd_pld ocd_pld init
Debug: 379 334 pld.c:205 handle_pld_init_command(): Initializing PLDs...
Info : 380 334 server.c:312 add_service(): Listening on port 3333 for 
gdb connections

I'm using
   -f interface/stlink-v2.cfg  -f target/stm32f1x.cfg -d3 -l openocd.log
in the config options.

It seems to listen but gets nothing, yet the ARM tools including 
arm-none-eabi-gdb.exe are in the right path or the project wouldn't build.
Reply by David Brown ●August 29, 20172017-08-29
On 28/08/17 23:40, Mike Perkins wrote:

> On 28/08/2017 22:36, John Speth wrote:
>> On 8/28/2017 2:24 PM, Mike Perkins wrote:
>>> A year or two ago I put together an IDE using eclipse, gnu arm tools,
>>> openocd with a st link JTAG adaptor.
>>>
>>> I can't seem to get a working system together, and further more some
>>> links aren't working I have used to install add-ins for Mars 2. Mars 2
>>> was the system I know worked.
>>>
>>> Is there a blow by blow account of how to install this with either
>>> Neon or Oxygen, or should I bit the bullet and use an IDE already put
>>> together.
>>>
>>> Does anyone here have any suggestions? Yes I know of pay-for solutions
>>> but they're not ideal for multi-site solutions, plus the old system I
>>> had worked just as well as any pay IDE!
>>
>> You mean: Worked just as well ... , until it didn't work.
>>
>> Sorry for the negative reply but it sounds like now you're paying for
>> the hidden cost of free.
> 
> Yes, I'm aware of that, except some of the links whilst in 'Help>Install
> software' no longer work. Perhaps its a weekend/holiday thing.
> 
> Mind, I've know paid licensing issues cause as many nightmares!


You haven't given much details of the problem here (not that I can be
sure of giving helpful advice even if you had...).  It is possible that
for some of the bits and pieces you have used, they have changed project
location - moved from Sourceforge to Github, or whatever.  Personally, I
usually try to avoid updating software like this.  I install an Eclipse
build or other IDE in a directory, and leave it there - if I want a new
version of the tools, I do it in a new directory with a separate
installation.  I am particularly fussy about the key tools - the
compiler and library - and never change these in a project.

I don't know how far you get with your current setup before things go
wrong, but sometimes it is settings in the workplace that are the
problem - try creating a new blank one.

And I expect that ST have a free IDE with gcc ready for download - most
ARM microcontroller manufacturers do (but I haven't used ST's devices).
 You usually don't get the latest version of Eclipse or the gnu arm
embedded toolchain, but you get an all-in-one package that is normally
easy to install.
Reply by Tilmann Reh ●August 29, 20172017-08-29
Mike Perkins schrieb:


> Does anyone here have any suggestions? Yes I know of pay-for solutions 
> but they're not ideal for multi-site solutions, plus the old system I 
> had worked just as well as any pay IDE!


You might have a look at Code::Blocks.
I like it very much.

Tilmann