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.
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 firstname.lastname@example.org
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.
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 problem. Supposedly they were made to identical specifications, but for whatever reason the ones made in Vietnam were not as reliable.
If the problem is the E1, I would suggest that you purchase the low-cost E2-Lite (~$60USD) which supports RL78 and works great, there is no compromise between this and the higher cost E2 or the E1 for RL78.
The one feature missing with the E2-Lite is that it does not support supplying 5V to the target. It can supply 3.3V, and it support both 3.3V/5V if supplied externally (i.e. not with the debugger).
Yes, you're right my E1 is made in Vietnam. Bought on Mouser from USA.Here's what I'm thinkingIf you are aware of this problem, then Renesas certainly knows about it.And the driver on the E1 is dated 2011.those. no attempt was made in the driver, firmware, or instructions for hardware to solve the problem.And why, for example, Toyota recalls its cars because of the rug, in which it is easier to make a hole so that it does not interfere with the pedal, but the Renesas corporation simply ignores the problem.It's more like the Chinese ... and it's sad.Thanks for the advice on e2Lite, but the problem has been solved (in my reality), and given the fact that the RL78 is not currently available for order, I do not think that it will be useful to me.But I am still waiting for an official explanation from Renesas on this matter.