I have problems with KD30. I can't get it running with a simple program like just blinking one LED at P1.0.
I tried an older versions of HEW to make a .x30 file and KD30 loads it fine.
But doesn't work very well. The GO button only STEPS. (But maybe it is my USB to RS232 converter. Always timing problems with these devices).
I was also confronted with Bugs in NCRT.a30, fset i, wrong vectors etc.
Because of these troubles which all ready make me desperate for a number of days,
I decided to switch to the latest version of HEW with I hope bugless files and operation.
So I installed the latest version 4.09.00.007. toghether with the KD30 debugger. V4.10.
Target is an older developped R8C11 board. But of course like all the Renesas tools it does not work imediatly .
First aim of Renesas is appearently to make you crazy, helpless, desperate and very AGRESSIVE. #@#@#@
KD30 starts, monitor is loaded but when loading the module it gives an error 1554 : target file has not the specified format .
(or error 1551 cann't open target file)
The module to be downloaded (output of HEW) is an .abs type.
I think KD30 needs a .x30 file.
The question is: How to define .x30 as an output of HEW. I really can't find out how. Nothing is mentioned in manuals, help files or what so ever.
Specifiying the debug format to IEE695_RENESAS or other does not help.
Actually this question , how to make an .x30 file with HEW, has been posted before I saw.
The answer was, by the poster itself, "Yes I found out how. Thanks". But did not tell it HOW he did it.
This could have been helpfull for other (desperate) members I guess.
Thanks in advance
HEW is only a stupid IDE with editor and project management. It does not change anything on the compiler output. The compiler version is the important thing.
If you upgraded to NC30 V.6.00 you cannot use KD30 any more as NC30 V.6.00 uses Elf/Dwarf as debug format, not IEEE695 which was used by NC30 V.5.xx.
Instead of KD30 you can also use the HEW debugger plug-in for FoUSB/UART (http://www.renesas.com/support/downloads/download_results/C2002801-C2002900/upgrades_m16c_fousb_dbg.jsp). This is the HEW version of KD30 and can support Elf/Dwarf.
Thanks Frankl. I thought so.
So now I tried a new start. First get rid of everything. How difficult can it be. In XP: Config/software/Remove program (HEW)
Appears to be NOT POSSIBLE . Do I have to Format the C drive for this????. $#@#$@#.
Okee calm down.
Installed the next things:
Appeared to go smoothly.
Oke. HEW is running, NC30 is compiling, Connection with my R8C target using the serial port is working. That is GOOD.
Monitor program is downloaded to the target. Roger. Also GOOD.
But then: How can I start the %$#%@ FousbDebugger.
Debug sessions / Target = M16C R8C FoUSB/UART, DEBUG format (tried all the formats)
SETup / Debugger/ = external debugger is Renesas PD debugger/
PD debugger location: C:\MTOOL\PdTargetServer.exe,
I guess (Why doesn't the #%$@# program know where it is. He installed it himself) Or is it in tools/renesas/ etc (path mentioned while installing).
Where is the $@#%@$# PD installed anyway???
I pushed the hammer debug button . I am waiting now for half an hour or so, but no debugger has appeared. No download to the target. This is NOT GOOD.
Another valuable evening thrown away. Thanks Renesas. Thanks very much and thanks in advance for the next comming frustrations.
What do I do wrong. Or is it simply not possible. Am I ambushed?
PS. Funny when I look in the taskmanager PDTargetServer.exe runs at least a 30 times.
Sorry, but what are you doing?
You know what PDTargetServer is? It is NOT a debugger. PDTargetServer is a COM interface application in all Mitsubishi debugger used by external applications to talk to the debugger. And it should not run at all (unless you have some external application that tries to talk to a PD debugger). Usually you should go to "Tools" > "Administration", select "Extension components" and unregister PDTargerserver and HEWTargetserver.
"Setup" > "Customize" > "Debugger" should be set to "None selected". It is only for starting external debugger like your old KD30. It is NOT for starting integrated debuggers.
In HEW debugger run in "Sessions". The easy way to create a session (if you didn't create them already when setting up a new project) is to go to "File" > "New Session" and generate a debug session.
In the tool bars in HEW you need the "Standard" toolbar and the "Debug" toolbar. In the standard toolbar you have a pull-down to change the session (each session has its own toolbar set up!), and in the debug toolbar you have the green button to connect to the debugger.
When you use NC30 V.5.xx the debug format is always IEEE695_RENESAS.
In an existing project the download module is best defined as "$(CONFIGDIR)\$(PROJECTNAME).x30" because this setting works wherever you copy the project.
Oh, and the debugger are installed to Hew\Tools\Renesas\DebugComp\Platform\PDTarget\
I got things running now.
By creating a new SESSION as you described no changes in pull down tabs was seen.
But by creating a new workspace and choosing the debugger to be used, it appeared in the toolbar
So downloading to my target is now succesfull. But running not yet.
The program doesn't run smoothly (after pressing the GO button).
It runs a bit around in sect30.inc and ncrt.a30 for a short while.
And then stops and reports.: "Cause of break: Halt."
Single step is possible. A GO or Free Run also results in a single step. Each time: "Cause of break: Halt."
The MAIN is not reached (actually one time I succeeded after a lot of single steps)
I had the same problem with KD30. So I guess it has something to do with some included files.
Is this a known problem? Is there something wrong defined (RAM/ROM area, Vector adress :
0fedcH (or must this be 00fd00H like in the old days) ) ?
I use ncrto.a30 2006/04/18, rev 2.00
sect30.inc, 2007/11/29 09:02:11 Revision: 220.127.116.11
nc_define.inc : "This file is generated by Renesas Project Generator (Ver.4.18)"
Or just a mysterious setting in HEW?
The compiler version used to generate the project would be better....
In compiler V.5.42 there has been a bug in the assembler start-up code with stack set-up
In compiler V.5.40 and V.5.44 there have been bugs in the C start-up code.
Things are up and running. The LED's are blinkink.
The problem was in the ncrt0.a30. I already used the corrected one where you were refering to in the first link.
But I changed the following part:
; Initialize standard I/O
.if __STANDARD_IO__ != 1
I changed the line .if __STANDARD_IO__ == 1 to != 1 (shown above). Like in the old versions of ncrt0.a30
Now this part is skipped.
It is where the program was running around in the debugger.
I cann't oversee the consequences for the future but so far so good.
Thanks for your help (until now)