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.
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.
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.
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?
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?
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.