Flash Write in H8SX/1653 controller

The first source to look in is the Hardware manual for the device, as section 20 has the vast majority of the information.

What are you trying to write to flash? Data or new programme code.

As with the vast majority of controllers with on chip flash, this flash cannot be read from (including programme execution) whilst programming. So in user programme mode the code to write into flash has to exist in RAM (usually internal RAM).

Either your whole application is transferred to RAM at startup, or you use a relocated piece of code held in flash that is copied to RAM to execute, or use some form of inbuilt (hardwired) bootloader to transfer the downloaded programme to flash.

If you are trying to use areas of flash as data flash storage you better have some part of RAM permanently reserved for flash erase/write code that is copied to RAM at startup.

Whilst writing to flash all sorts of interupts and other functions MUST be turned off. So it is not wise to use the internal flash for data storage that perfers to be written to in blocks of 128bytes.

If you provide more information perhaps people can help more.

Ya , As u says,

"As with the vast majority of controllers with on chip flash, this flash cannot be read from (including programme execution) whilst programming.

So in user programme mode the code to write into flash has to exist in RAM (usually internal RAM)."

This is correct for our controller also.in H8SX/1653 There is ram emulation register through which we can access the flash.We are doing firmware flashing through E10 emulator provided by renesas.The problem is for data storage in flash through user program mode as i sais in previous mail.

Normally in boot mode we can dump the data through some loader program.But in our case we have to access the flash from our firmware running in user mode.

The data will come from the Windows front end along with command for writing in flash.We have to get it and write it into flash.

Regards Vairavan

Ya , As u says,

"As with the vast majority of controllers with on chip flash, this flash cannot be read from (including programme execution) whilst programming.

So in user programme mode the code to write into flash has to exist in RAM (usually internal RAM)."

This is correct for our controller also.in H8SX/1653 There is ram emulation register through which we can access the flash.We are doing firmware flashing through E10 emulator provided by renesas.The problem is for data storage in flash. Its only possible through user program mode as i said in previous mail.

Normally in boot mode we can dump the data through some loader program.But in our case we have to access the flash from our firmware running in user mode.

The data will come from the Windows front end along with command for writing in flash.We have to get it and write it into flash.

Regards Vairavan

NO, NO, NO.

The Flash Emulation Register is to map a part of the Flash address space to RAM, so any accesses that would have gone to that part of Flash would go to RAM INSTEAD.

This is described in the manual very well.

By data I assume you mean that only PART of the internal Flash will be erased and rewritten in such a way that the blocks being erased do NOT contain any of the firmware programme.

Which means you have to make PART of your application at that stage run in RAM, all of the flash mode changing, downloading data, erasing and writing to blocks of Flash PROGRAMME has to be in RAM, i.e. copied there first. The rest of your application has to STOP, as this likely means that to use the RAM area for software to run while mean you lose area of RAM for data storage this is NORMALLY done from a reset to stop lose of application data.

If you application uses very little of the RAM space then you MIGHT be able to load the software and buffer space into RAM and change modes to do the programming.

Erasing/Programming the internal flash means your application MUST STOP and a dedicated single task application to handle the download and storing of the data area must be loaded into RAM and run.

How you switch to this mode in your application is for you to decide, and how you switch back again is also for you to decide. Most applications doing this sort of thing perform a software restart after programming to stop undetermined behaviour, ensuring all ports are back to reset state.

How to use the flash and set modes is described in the manual.

Be sure you understand the difference between the various modes from hardware reset and user programming from an application.