Work in IAR 4.21 with E1.Windows 7
It is very rarely possible to connect with target.
And after an unsuccessful attempt, E1 must be distorted.
All connections are available.
External power supply, power supply from E1 - no difference.
The connection is correct. separate renesas programmer sees and programs.
the problem is somewhere in the IAR, since in the case of a non-connection from the E1 side, there are no attempts to jerk the pins.
I ask for help or ideas in solving the problem.
It may be worth noting that the later E1 debuggers that were made in Vietnam had problems on some computers, depending on the USB chip set. The earlier versions that were made in Japan did not have this…
Here are some things you can try:
- Does the IAR configuration work reliably with a Renesas reference board (something like the ~$20 -TB or fast-proto reference board)?
- Is your debug connection following the guidelines provided in the document E1/E20/E2 Emulator, E2 Emulator Lite Additional Document for User's Manual (Notes on Connection of RL78)?
- Does your hardware layout position the 14pin connector as close the device as possible to minimize the lengths of the circuit board traces?
- Check if serial programming is reliable / stable using RFP with your E1 on-chip debugger.
- CS+ for CC (Renesas IDE/Debugger), does this work with no problem connecting to the device?
Thanks for your answer, so:
> - Does the IAR configuration work reliably with a Renesas reference board (something like the ~ $ 20 -TB or fast-proto reference board)?
I don't have any debug boards available.
> - Is your debug connection following the guidelines provided in the document E1 / E20 / E2 Emulator, E2 Emulator Lite Additional Document for User's Manual (Notes on Connection of RL78)?
Yes, everything strictly complies. Figure 2-5 Example of Connection between the 14-Pin Connector and the RL78 Family MCUs in General.
> - Does your hardware layout position the 14pin connector as close the device as possible to minimize the lengths of the circuit board traces?
Yes, this is a 14 pin cable that was supplied with the E1. length 150 mm, then my board with a connector for 14 pin. All connections are in place, checked by a tester. E1 also passes its test.
> - Check if serial programming is reliable / stable using RFP with your E1 on-chip debugger.
Everything works well with RFP, but if IAR breaks through to connect, then when I try to program RFP, I see this:
Target device: R5F1006C
Connecting the tool Error (E3000204): An error occurred while communicating with the tool. Operation failed.
But if you reconnect the device,
then the RFP will work many many times, without errors.
> - CS + for CC (Renesas IDE / Debugger), does this work with no problem connecting to the device?
If you can tell more about it? I only have IAR.
I would like to tell you once again that all attempts to communicate with the IAR do not cause any action on the 10 and 13 pins, i.e. the #RESET signal is not generated,
the # TOOL0 signal on pin 5 is also not present. And this attempt by IAR to do something with E1 results in the loss of communication with RFP.
I have also tried running IAR with administrator privileges, that also fails.
I tried different drivers with E1, they are all suitable for RFP but not suitable for IAR.
By the way, sometimes it is very rare to connect to IAR, and then debugging goes smoothly.
But these cases are extremely rare, and the IAR freeze lasts for 3 minutes, and this is not encouraging.
I wrote the same to support IAR but I don't believe that they will give a good answer,
I don't even believe that they will answer.
I would highly recommend that you purchase the very inexpensive QB-R5F100LE-TB, this is < $20USD at Mouser & Digi-Key. Very valuable to have a known good reference board.
What I meant by the placement of the connector was on your PCB, how close the 14pin connector was located to the MCU on the PCB. Also if other signals are routed near these traces this can impact signal integrity.
It appears that your device is R5F1006C which is G13, but figure 2-5 shows the recommended connection for G11 & G12 devices. You should be using fig 2-4 recommended connection.
CS+ is the Renesas IDE, it license free for debug-only use (without a license the compiler is size-constrained for use). I always recommend to first get this debugger working, and once this works you can move to a 3rd party tool such as IAR. e2studio is also a Renesas IDE but this is Eclipse based, I find CS+ easier to use for the simple things like first-time establishing a debug connection with hardware.
[Evaluation Software] CS+ for CC V8.06.00 (Single Download)
CS+ does not officially support the ELF-files generated by IAR, but I have had decent luck using more recently with IAR executables for RL78. You don't need to use this for debugging your IAR build, I am only recommending thisly for testing the connection to the hardware.
If you don't have a support contract with IAR they will not be much help. Even with support for IAR, for something like this they would probably tell you to talk to Renesas anyhow, since the debug executive used by the IAR IDE is provided by Renesas.
Renesas has 2 documents, I used R20UT1994EJ0800 Rev.8.00and there is a picture in it that is called 2.5 in your 2.4In any case, 1 kΩ and 10 kΩ are present and the circuits are the same.I installed CS and found out that the connection in it also fails.
Sometimes it crashes CS sometimes long wait
RFP work is also restored only after reconnect.
add error CS log
Contact Info (20220109190728).rar
and source test progectCS_test.rar
Perhaps I have not configured something somewhere, the CS does not seem simple to me, in this regard.
RFP puts the device into serial programming mode, where debugging uses normal mode. Slightly different operating conditions but usually if one will work the other will work. Since CS+ is also having issues, there would seem to be a problem with the hardware.
If you haven't already, make sure the device is fully erased using RFP, before trying to connect with a debugger.
If you could share your schematic that might be helpful to review.
Yes, of course I tried to completely erase the chip using RFP. But the mistake was repeated again.
This was tried on another version of windows 7.
I still hoped that the problem was in windows. I will repeat once again that E1 does not generate RESET and TOOL0 signals. I tested this with Logic Analizer (LA2016) and if you could think that I did not notice the blinking of the LED, then LA2016 would notice :) but they are not.
And now I decided to put CS + on my windows7 that started it all. And CS + starts but Crash happens when the project is created or opened. so I cannot test it to work on this version of Windows 7.
Here is my schematic for the connection part.
And here is how the tracing is done.
I tried power supply from E1 and from the power supply unit UDP3303A.
I also tried to change the USB cable, although it seems pointless, but the logic is already leaving me.
IAR's answer as you said :)
Thank you for contacting us!
As you don’t have a full commercial license for the Embedded Workbench out technical support is unable to assist you further.
This issue is not easy to solve without further investigation and our support teams suggested that you contact Renesas for advice via email@example.com
I wonder where renesas will send me ...
It looks like you have a pull-down on the reset-pin instead of a pull-up (R22). It also appears that you have no external reset circuit, in which case the following recommendation applies from the debugger document:
You also have a 1K pull-down on VCC which is not necessary (R21).
I believe you need to remove R21 & R22, add the 1K-10K pull-up on the reset line, and cut the trace to the 14pin debug connector pin#6.
R21 and C5 are my reset circuit. and R22 is 10 kOhm in series from the connection point of R21 with C5 to RESET. you may have been led astray that GND is signed under the line, but the line is not GND, it is RESET.
VCL - power supply to MCU in 2 case 5V.
I even tried removing C5, but no effect.
It seems to me that if # 6 is removed, debugging will be impossible. pay attention to Note 4:
The RESET_IN pin is used only in debugging. The emulator operates for flash programming by the programming software whether this pin is connected or not.
That email address is for European customers of Renesas. If you were going to submit a ticket it would be better to use the Submit a Technical Support Inquiry portal that will route to the correct region and the correct support group.
That is correct - RESET_IN is only used for debugging, to allow the debugger to mask an external reset.
Your circuit really is neither recommended connection example for with or without an external reset circuit. Since you have no external reset, you should disconnect pin6 of the debug connector from the circuit, and leave C5 unpopulated (a low-pass filter on the RESET is going to affect tool timing trying to establish a connection to the device). The 1K +10K should still work although the recommendation is between 1K and 10K.
> That is correct - RESET_IN is only used for debugging, to allow the debugger to mask an external reset.
If possible, explain this point. I saw masking in the IAR settings, but I do not understand the essence of this action.
I removed C5 R21 and R22, R21 I soldered between # 8 and # 10 connector.
As before, sometimes the IAR can connect, but more often than not it hangs.
I removed 2 logs from USB, and they show that E1 is returning an error.
But ... we do not know the meaning of the E1 commands, and we also do not know what kind of error it is.
this OK connection
this Error connection
Consider the above circuit. The external reset signal can be driven low, asserting a reset but the debugger can override this because of the resistance between RESET_IN & RESET_OUT, masking the external reset.
I'm sorry but the USB logs are not useful for me, maybe a Renesas tool support person from Japan could understand something from that data.
It sounds like you have pin6 open and the RESET_OUT pulled-up now, I don't know why you are having problems. You might consider submitting a support ticket at the Submit a Technical Support Inquiry portal.
Yes, thanks for the explanations, now I understand why there is a resistor.Yes, I understand, in order to know what is happening, you need to understand this data. And only the developer of E1 knows them.
I have now gotten E1 working properly, but the reason remains unclear.I installed IAR on a Windows 10 notebook and everything works fine there. I got my wiring diagram back, but it still works well. I tried this many times but no problems were noticed.Perhaps there is a hardware conflict, but I have nothing but a mouse connected to USB, and this is HID.maybe we are dealing with microsoft, then we will not win.Tomorrow I will get the SSD and install the W10 on my computer, maybe that will fix the problem. I will write about the results.Thank you.
As promised, I continued my research.I installed a fresh W10 on a blank SSD and IAR 4.21.2, but the problem persists.Everything still works on the notebook.I connected the E1 to the front panel (I have USB2.0 and USB3.0 there), usually I only use it for Flash memory and it worked. IAR gave a consistently good connection. On the same panel, USB2.0 again resulted in an error. Then I went back to W7 and IAR also worked only on USB3.0. From the back of the computer, it still works well on USB3.0 and does not work on USB2.0.
I have compiled a report on this issue.and sent it as you advised to support.registered under number 344241.I also continued to communicate with the support of IAR who, despite the company's policy, provided assistance.This report was also sent to them.As soon as I receive an answer, I will write it here, so I ask the administrator not to close this topic.I thank JimB for his patience and advice. Without them, perhaps I would not have continued looking, but would have limited myself to debug output and RFP.