KDS Settings Issues

[mjbcswitzerland]

Hi All

I have ported a project previously used with CW10.5 to KDS and have had the following difficulites:

1. Builder Settings.

The build directory is set to ${workspace_loc:/project_name}/Project_Flash but this is not the location that it should be in for this system. CW10.5 allows the correct location to be set here but KDS has the field greyed out.
It can be set when "Generate Makefiles automatically" is disabled but gets set back to the unwanted default when the check boy is activated again.

2. It looks like the newer GCC version doesn't accepts asm() but needs __asm__() instead (not a problem but it had to be changed in the code)

3. Presently path variable are getting dropped when used in the tool settings. For example it is possible to use a linker script path such as "${ProjDirPath}/Project_Settings/script.ld" but if ProjDirPath is replaced by a valid path variable (eg. PROJECT_LOC, which is the same location) it results in the linker just receiving "-T /Project_Settings/script.ld" [the path variable has been completely lost].
This is presently requiring some absolute paths to be set, which is obviously an emergency solution.

4. The same as 3. is also true for post build steps. Here the variable ${ARM_GNU_TOOLS_HOME} is also getting dropped so the post build bat file doesn't know where the tool chain is.

5. I have seen that there is an option in KDS which was missing in CW10.x to set which output format is to be generated (eg. SREC or RAW binary). In many circumstance (eg. when outputs for boot loaders are generated) it is desired to have multiple format types. Since objcopy is used to convert from the axf to the desired output it may be more convenient to offer some check boxes so that multiple outputs can indeed be selected - otherwise a post build step is needed anyway.

6. In the Flash from File utility configuration there is no P&E support as there is in the standard debugger connection. Is there a method to use P&E types thsi way?

Regards

Mark

[BlackNight]

Hi Mark,

Lots of questions and points, so I try to answer all of them as best as I can....

First (see FAQ's), CodeWarrior projects are not 1-to-1 compatible to KDS, as KDS is using a different toolchain (and different Eclipse).

1) The build directory is controlled by the build plugin: it uses the configuration name with the project location (in other words: the output folder is the path tot he project folder with the name of the configuration attached. If you want to change the name, then you can use the 'Manage Configurations...' button:

2) It is not because of gcc itself, but of the language option. The default compiler language settings (ISO C99) only accepts __asm():

You could switch it to ISO C90, but my recommendation is to use __asm() instead.

3) Yes, this is a known problem with any Eclipse distribution (with CodeWarrior just one): every Eclipse distribution comes with its own variables, which then might not be present in another distribution. PROJ_LOC to my understanding is an alias used by CodeWarrior from the early 10.0 days. I recommend to use the 'standard' ProjDirPath one. You can get a list of currently visible/active variables with the 'show system variables' check box:

4) Same thing here: CodeWarrior only has this variable. You could use the eclipse_home variable to locate relative binaries.

5) KDS is using the GNU ARM Eclipse toolchain (Welcome to the GNU ARM Eclipse Plug-ins! | GNU ARM Eclipse) and correctly uses the file extension. It only supports one output file, if you need multiple, you need to use a post linker step, or file a feature request for the GNU ARM Eclipse plugins. But I think typically only one format should be enough.

6) No, not yet. But I have this added to the (aehm, growing) list of items.

Thanks for your feedback and input!

Best regards,

Erich

[mjbcswitzerland]

Hi Eric

Thanks for the first answers.

To 1. I don't want to change the target "name" but the target "build location". I can do this with CW10.5 and also with Atollic.
That is, I want to change the ${workspace_loc:/project_name} part and not change the Debug part.

The reason is that having the output directory at that location causes a "mess" in the project structure and difficulty to maintain output binaries.

This is the biggest issue that I presently have.

To 3 and 4. I can use path variables without problems in CW10.5 and Atollic, but they fail in KDS.

The problem is not that there are differently named build variables between different versions but that one can not use path variables (as defined in "Resouce | Linked Resources"). Even the ones that Eclipse defines as default there can't be used and, although one can define new ones which Eclipse also says are valid they can't be used.

However I have found that I can also define build variables based on system build variables and this then allows these to be used as macros to define, for example, the linker script path.
Path variables are project settings and as long as build variables are also stored in the project this alternative solution is adequate.

To 5. I can live with a post build bat file but the fact is that I always need BIN, SREC and HEX outputs and not just one of them. The reason is that

- I use the HEX output to load to the TEENSY 3.1 target with its HalfKay Boot loader mode - Getting started with Teensy USB development board (it only accepts this format)

- binary output to program to boards with USB-MSD boot loaders installed
- SREC outputto load to boards with SREC loader installed

Therefore is is much faster and efficient to just generate all outputs so that they are "always" available when needed. objcpy is so fast that you don't notice the extra work.

To 6. One idea that you may consider for this utility is to recognise HEX files. The CW10.5 utility automatically recognises SREC files and binary files but doesn't recognise iHex files. I understand that there is no real need to support iHEX format as well as SREC but there is danger involved when a user selects an iHEX file by mistake and loads it with the utility. The utility decides that it must be "binary" and loads this content directly. Thsi is dangerous since its content looks like ":1006B0002EF88DF80B0001208DF8100001A803F032" and such lines are programmed to the Flash configuration area (0x400.0x40f) resulting in Flash sectors being set protected and in the worst case other nasty things like JTAG being disabled forever

Another useful option (would also solve the iHEX case) would be to disable writing "special" data to the Flash configuration sectors (as IAR and Rowely Crossworks do as standard) to avoid locking chips by mistake when loading bad code. Rowley told me they did it due to the fact that they had bad experience with users locking chips by mistake so they prefer to be safe. This would be simple to do (always load a standard pattern to this area when an override check box is not enabled) and would avoid lots of support cases where (new) users can't work out what has gone wrong.

Regards

Mark

[BlackNight · Accepted solution]

Hi Mark,

on 1) I checked with my stock Eclipse Kepler, and it is the same: I cannot change this if using automatic make files. To me this seems to be a thing of Kepler. In Eclipse Juno (CodeWarrior) this was indeed different. But for Kepler this option is not changeable if using automatic make files (http://help.eclipse.org/kepler/index.jsp?topic=%2Forg.eclipse.cdt.doc.user%2Freference%2Fcdt_u_prop_...)

On 6) This is up to the low level flash programmer. For example Segger has this with 'security' and 'normal' configuration files. If you select the 'normal' configuration file with Segger, it checks that you are not bricking your board. With the 'security' option everything is enabled.

Regards,

Erich