Crash when compiling old project with new M16C Toolchain

Hi,

I just set up a new Win XP machine and installed HEW 4 from a CD I got lately with a Super H dev.kit. I also installed the M16C toolchain from this cd.

I ran the autoupdater and it downloaded maybe 200MB updating virtually everything.  (I am on a different machine right now, but I can look up the exact version numbers later).

I played around with the Super H dev. board, compiling and running a few programs and everything worked out fine.

I then copied an old R8C/13 project to my new workspace folder, that I had been working on with an older version of HEW and the M16C toolchain (again I can only look up the exact version numbers later. The installation is about two years old and has not been updated since.)

HEW imported the project and informed me that it would do backup copies where necessary etc.

I hit F7 to compile the project and out of the 20 or so sourcefiles, 2 of them provoked a crash of nc30.exe

For these two files the log window would just state the start of the compiler followed by the well known Windows XP crash alert, telling me that nc30.exe has unexpectedly quit (and if I wanted to send a bugreport to microsoft etc.)

Now the good thing was, one of these crash files was a pretty short one, just a few lines of code and only two include files. So I created a new R8C project and added just these files. However, this way it compiles without any problems.

I am a bit lost on what to try next. Among the uncounted compiler options in the toolchain settings, which would be the most promising to start playing around with? The optimization is set to max. to stay inside the 16K limit of the R8C/13, but I tried turning that off already, the crashes however persisted.

These whole project needes to be migrated to a MCU with more flash (which will be the /21, see other thread) but I got a feeling it might be a good idea to get everything up and running the way it used to with the old setup first.

Any hints and help is much appreciated,

Sven

You could check your options. In "Build" > "M16C Standard Toolchain" you see at the bottom of each tab a text box which shows all selected options for compiler, assembler, linker, ... .

You should check if there is a difference to the default project.

A nice thing are often special characters from Languages other than English (like ä, ö, ü, é, ô, ...). These characters are coded in ASCII with value > 0x7F. But with the default settings the compiler is often not able to do thie and sometimes crashes. The compiler has to environment variables which influence language interpretation. If you use the compiler from HEW, these settings are also hidden in HEW. You have to go to "Tools" > "Administration", select your tool chain, click on "Properties" and go to the "Environment" tab. There you find 2 envirnment variables NCKIN and NCKOUT. By default they are set to "SJIS". To support special characters (at least for European languages, others I don't know) these values should be changed to "EUC".

I checked the options and found nothing unusual (besides two custom include paths and the optimizations turned on I had never changed any of the default options on the old project anyways).

I tried to change NCKIN and NCKOUT, but the "Add", "Modify" and "Remove" Buttons in the Environment dialog box are grayed out (doubleclicking any entry doesnt help either).

So, I created a complete new empty project, left everything set to defaut and then added all the source files to it. Didnt help, the crash remained with the same two source files.

I then removed all the source files, except for the one file that did crash within the project but did work when being added as the only file to a new project. Funny, it did not help. Even with the project stripped down to this single file, the compiler did still crash.

I then again created a new project and added the source files one by one, rebuilding the project after every single file. Of course I got lots of errors and warnings during the process, but to my amazement not a single crash. After adding the last source file, I had to turn on the optimization to make it all fit into the 16K and after a "Build All" i got the message that made my day:

"Build Finished
0 Errors, 0 Warnings"

Would it be of any help when I zipped and sent to you the other test project that now only consists of one source, one header (< 100 lines of code) and the sect30.inc file and reliably crashes nc30.exe on my installation?

Because right now i feel a bit odd about the fact that I do not know what exactly caused the crashes, what healed them and when they might occur again.

Regards,

 Sven

It would help to know which version of NC30 you are using now on the new machine. What SH kit did you get the install CD from? (I know the autoupdate did it's thing, but sometimes it helps to know where you started.)

Ok, I think I nailed it.

I was zipping the project for Frank and unzipping to my desktop before sending to see if it crashes when opened from there. I did not, it just compiled without problems.

Thinking about how Frank had to create a bunch of folders to reproduce my setup, I was wondering if this could actually be the problem already.

I do not have my WORKSPACE folder sitting in the root dir of C:\ but instead in a "Projects" folder in "My files" (simply because "my files" are covered by an automatic backup).

Then I recalled that from my project which started all the trouble, there were only two files that would actually cause the crash. It were indeed the two files with the longest names of all of them ("74hct4094.c" and "mc01_controller.c", the others are only 8 characters or less).

I thus created a new workspace folder sitting directly on C:\ and copied my troublesome project in its original old version from my old machine to there. HEW again noticed the older toolchain formerly used, offered to update everything and to correct the path settings and voilà, it compiled flawlessly.

So it all comes down do a simple string limit for filenames and/or paths in nc30.exe. This might even be documented somewhere and I just did not notice. It might also be carved in stone that WORKSPACE always has to reside directly on C:\ and I just did not realize. If so, my apologies. If not, a future version might at least output some complain about longish paths instead of crashing to save others from some intense research.

The version numbers are:

M16C Toolchain 5.43.00

M16C Compiler 6.01.00

Dunno if these are involved:

M16C Configurator 3.30.01

M16C Load Module Converter 4.01.01

Regards,

 Sven

PS: The SH kit was a EVBSH7125 Carrier Board V1.2 from Glyn