Why can't I load code with the debugger ?

My target board is wired with Renesas Microcontroller Unit M16C/6N5 Group. Device M306N5FC. The target board is connected to Renesas E8a Emulator or debugger. The debugger software that I'm using is Renesas High-performance Embedded Workshop Version I start the debugger program. I click on connect. I select the MCU Group and Device. Then, for mode I select 'Erase Flash and Connect'. I then select 'Power Target from Emulator' and select 5 Volts. I click OK. While the debugger software is connecting, it says flash memory is erasing. I am using this microcontroller in single-chip mode. I view the contents of internal ROM. They are erased except the vector table at 0xFFFDC - 0xFFFFF isn't erased. Then, I try to download my executable that contains debugging information. It always downloaded the code to internal ROM but now it never works. Debugger displays the following message: "Memory area error. It overlaps the system range". Internal ROM is 128-Kbytes. It's address range is: 0xE0000 - 0xFFFFF. To the best of my knowledge I didn't change anything. Why suddenly I cannot the load code into ROM. This flash chip is rated for 100 write cycles. Have I exceeded the write cycle limit? I have spaghetti wiring between my target board and actuators. Could this be wiring issue? I look at the release version of executable, Motorola s-record. It's all FF's, except address range 0xFC000 - 0xFFE4D has data. This must be the code I'm loading with the debugger. This is within the system range.
  • When connecting the debugger it asks for 2 memory regions to be specified, the working RAM area and the rom area for the debugger code (HEW has to download code to the processor) These addresses shouldn't overlap with code you are using.  From memory the Ram requirement is for 80hex bytes and the rom for 400 hex bytes.  Also your image should not include the area that covers the fixed vector table at the top of memory as this is also required for the debugger.


  • In reply to Paul Brown:

    What Paul wrote is correct except for the fixed vector table. It is correct that E8a uses the fixed vector table for its own purpose (reset vector pointing to start of debug monitor, initialising some debug interrupts). But you must not move your own fixed vector table as E8a will do this for you.

    It is necessary that E8a does this because it reads the reset vector from the relocated table. If you move the fixed vector table E8a will not know the start address of your application.


  • In reply to Paul Brown:

    Thank you for the effective response.  I believe this is a erase problem.  Firmware Location tab in the HEW Debugger says Program Firmware is 0x800 bytes, address range 0xE0000 - 0xFF700.  When I connect to the target board with the debugger, HEW says it's erasing flash.  I believe it's erasing these 0x800 bytes.  After erase is completed, I inspect these 0x800 bytes.  Not all of them are erased.  Address range 0xE0000 - 0xE07F8 isn't erased.  That's a problem because my application that I load starts at 0xE0000.

    Erase/Program from debugger must have been working before because I never had problem loading my application from the debugger.

    The only explanation I have is that this is a internal flash memory problem.  Only 100 write cycles are guaranteed.

    Does the group agree with my thoughts?  I would like more opinions before I start replacing chips.

  • In reply to jani12:

    Just move either your start location, or specify a different place to put the 0x800 bytes.  I always specify 0xff0.  The 0x800 bytes are erased they are just re-programed with the E8a monitor program.

  • >> The 0x800 bytes are erased they are just re-programed with the E8a monitor program. Do you mean they are re-programmed when I double-click on my executable .695 file from the debugger? Or does E8a monitor program this area before I select my executable .695 file? It wouldn't make sense if this area had data in it before I started the program operation because the area needs to be in erased state before application code can be loaded. >> I always specify 0xff0. I believe this address won't work because it is internal RAM's address.
  • In reply to jani12:

    In the firmware location settings you will see the box for the program 800h Bytes Use followed by 00.  you only specify the top 3 nibble and 00 is appended so 0xff0 specfies location 0xff000.

    similarly with the work ram 0 is always appended so in my case I always use 538 with a 0 appended as the max address for my processor is 0x5380.

  • In reply to Paul Brown:

    Thank you for information about the firmware tab.  Few more questions about this tab.  Progarm  -  800h.  Where is 800h coming from?  Use-  E00   followed by 00.  

    (MIN : E0000  -  MAX:  FF700).  How does the debugger know my application MIN is E0000 and MAX is FF700?

  • In reply to jani12:

    The debugger does not know anything about your application.

    But the debugger knows which processor you selected and adjusts the memory range to this selection.

  • In reply to FrankL:

    OK.  I realized that after I asked the question.

    From the debugger Emulator mode tab, MCU Group is:  M16C/6N5 Group.  Device is:  M306N5FC.  Firmware location specified in the Firmware Location tab is as follows:

    Program - 800h Bytes Use-  E00 00

                     (MIN : E0000 - MAX:  FF700)

    When I erase internal Flash ROM from the debugger, starting at address 0xE0000 there is data.  Why?  That's my application starting address.  What is this data that getting programmed by the erase operation.  That's probably why I cannot load my application from the debugger.  About 800h bytes are being programmed by the erase operation.  Does this 800h have anything to do with 800h specified in the Firmware location tab.

    In this message chain, someone suggested to move my starting address to F00.  In Firmware Location tab I changed E00 to F00.  Now erase operation stores the exact same 800h bytes starting at address 0xF0000.

    What is going on here?  What am I doing wrong?  It was working all along.  I didn't change anything intentionally.  Please advise!  Is erase operation suppose to program 800h bytes at starting application address?

  • In reply to jani12:

    The tab in question refers to the monitor program code that the E8/E8a uses this is what the Firmware refers to not your program.

    The M16C has no on board jtag.  It uses an old fashioned monitor.  The 800h bytes is the amount of program that the monitor uses.  It writes this to the Flash so nothing is wrong and what you are seeing is correct behaviour.

    Your program obviously starts at E0000h if you specify this as the firmware location by specifying e00 (to 0s are then appended ) then the monitor firmware and you program will overlap.  Just specify FF0 and as long as you arn't using the top 4K for anything you will be fine.  In fact you can probably push it to ff6.  This does depend on where you have located your variable vector table you need to avoid that as well.

    You need to also specify ram address for the monitor program as well avoiding any you will be using.  Again I always use the maximum setting allowed for my micro.

    It is very easy to accidentally use the scroll wheel on the mouse and change the processor selection and then when setting it back the address has changed.