E10A-USB Lite and H8S/2378R Connection Issue - Failed To Identify MCU

Hi there,

I’m having a world of trouble connecting my E10A-Lite emulator (HS0005KCU11H) to a Renesas H8S/2378R via HUDI. 

The MCU is on a custom production product and the manufacturer has confirmed that all necessary components are populated on-board to allow the E10a to connect in the field. The board has a jumper to allow the MCU to enter boot/e10a mode and  I can confirm the main program halts when this jumper is moved.

When I try connect via HEW I’m asked to specify a clock speed and an MCU ID when the hardware is freshly powered up. Problem is, regardless of what is entered I cant get past this stage and I get a dialog with “Failed to identify MCU”. That said, there is no device entry for my exact MCU.

The onboard clock is 16Mhz and a 2Mhz PLL multiplier is used, and the source confirms the product runs at 32mhz - so I set the clock to 16 mhz when prompted by HEW. I did try a number of other values too but same error.

I have some questions, hoping people can share some expertise and suggestions, as I’ve run out of ideas and so have the manufacturer. I come from Microchip/Atmel development and I’ve found Renesas very convoluted so far, wasn’t expecting connection to be this difficult.

 

Question 1:

Currently I’m only using an evaluation compiler (v7 release 00), why isn’t there a device entry for the H8S/2378R when prompted during connection? I only see 2378F and 2378RF. It’s a huge burden even locating data sheets for these parts to find potential differences via the Renesas website. Even though the part is no longer recommended in new designs, surely the compilers should still support it. 

Question 2:

The manufacturer utilises tool chain 6.2.2.0 (paid version I imagine) in the source so I have had to upgrade my toolchain to v7. Is it possible that the older toolchain has the relevant drivers for that specific part that aren’t included in v7 now? Was 6.2.2.0 ever available as an eval version and can it still be obtained?

Question 3:

Is there any verbose output or debug log from the E10a connection process that could highlight what problems are interfering with connection?

Question 4:

With a multimeter or oscilloscope, is there anything I can check on the H-UDI socket pins on the PCB to confirm there is no damage to my product? Unlikely as it still works but just in case.

 

I appreciate your time and thank you in advance!

 

Environment details:

  • Windows 7 64Bit on Dell desktop and also via Parallels on 13” TB MacBook Pro (test program passes so not a driver issue with the e10a). Same behaviour on both.
  • Renesas E-Series USB Driver 1.02 release 00
  • H8S E10A-USB Emulator 3.04.00 (came with the CD, also tried with 3.06 too from website)
  • H8S, H8/300 Series Simulator/Debugger
  • Renesas C/C++ Compiler Package for H8, H8S and H8SX family V.7.00.00
  • High-performance Embedded Workshop V.4.09.01.007
  • General: The compiler has nothing to do with the debugger. V7.0 and V.6.2 only relate to the compiler. Only V.3.04 or V.3.06 relate to the debugger.

    You should use the latest version of the E10A-USB debugger which is V.3.06.01.

    The compiler have always only one installer for each version. If you have a full installer (no upgrade) it works as evaluation version until you input a license key. Evaluation version and paid version are the same compiler. Many years ago there has been an evaluation version of V.6.2.0 and an upgrade of this version from 6.2.0 to 6.2.2. The manufacturer of the board must still have the compiler.

    H8S/2378RF is a device of H8S/2378R group as you can see on the homepage.

    https://www.renesas.com/eu/en/products/microcontrollers-microprocessors/h8s/h8s2300/h8s2378-h8s2378r.html

    Compiler V7 has a completely different linker from compiler V6. Please have a look at table 18.1 and 18.2 in the compiler manual. They describe the differences in linker options between V6 and V7.

    If you run the device at 32MHz this is the frequency to be input in the debugger dialog.

    If the debugger asks for ID input communication with the device must have been established because otherwise the debugger would not know the ID has been programmed.

    If the device asks for an ID code it has been locked by the manufacturer of the application. But the debugger manual says the device should be erased if an invalid ID is input. This behaviour s strange.

    The device has also a hardware flash protection. The manufacturer of the application should know if it has been used.

    You could try to erase the device using flash programming software FDT and E8a debugger.

    That's all advice I could give. I don't have a H8S/2378, so I can't check anything.

  • Hello,

    Please let us know if you are satisfied with the suggested answer or if you need additional support.
  • Hello @FrankL, I spent some time examining your reply at great depth and have taken on board your advice regarding the target frequencies, compiler versions and even the suggestion to use an e8a to erase. Sadly, I do not have one of these.

    Unfortunately I have still been unable to connect to the target board and am out of ideas. Is there anything I can check on the H-UDI pins to determine whether the connector is in fact completely connected to the MCU?

    I can't completely determine whether the issue is my E10A-USB (unlikely, as it was new, unless I damaged it during my attempts), Windows drivers (again, unlikely as I have tried the CD drivers, online drivers and Windows XP,7,8,10) and/or the target board. Doesn't provide great clarity does it :)

    Any further suggestions or advice would be greatly appreciated.