Why would Erasing a Memory Block on M29F010 reset my Zilog 180

Hi all,

I am trying to erase memory blocks of the flash mem. above the code sections. Those regions are accessable with BBR only, and my window is address range 0xD000 to 0xDFFF. It just happens that Zilog BBRs match some of the M29F010 memory blocks. So BBR[0]=0xF, address=0xD000 means 0x1C000, or in Flash mem blocks is block number 7 that covers a region of 0x1C000 to 0x1FFFF.

Now, setting BBR to 0xF, doing that six step memory block erase procedure, using 0xD000 as the address of the block, is causing a 3 second delay and then rebooting, or sometimes it is just working fine but very rarely.

Why would this happen?

Thanks for any input.

Reply to
Tosca Berisha
Loading thread data ...

That can't work --- in general, you have to leave the flash completely

*alone* while it's erasing. Yes, that means you can't run any of the code stored in pages 1 to 6 while erasing page 7.
--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

You cannot run any of the Flash erase or programming code from the same chip (unless it's a special banked chip and the operations and code are in different banks).

--

Tauno Voipio
tauno voipio (at) iki fi
Reply to
Tauno Voipio

Tosca Berisha wrote in news:yNS4e.5366$6k4.655997 @news20.bellglobal.com:

blocks.

The M29F010 does not support erasing a block while still allowing access to other blocks. From your description, the code you are executing is in the same flash device? If so, then it is not at all surprising that Z180 is resetting. If you want to be able to erase during runtime, you need to execute code outside the flash device.

--
Richard
Reply to
Richard

Yes you are right, the code is executing in the first block. OK, I have an SRAM too.

I tried implementing something like making a c function in a module of its own, and then having it as a seperate section load into a defined address. Then at runtime I copy the that section into SRAM and then I jumpped to the erase function inside the SRAM. (What's bootloader supposed to do?) It is not working right now but is this a practical or logical approach. Is the way you do this kind of method?

Thanks TB

Reply to
Tosca Berisha

That's nearly how I do it.

I'm not sure if your toolchain allows it, but with the GNU toolchain, I compile the critical functions (chip unlock, erase, program, polling) to a separate section located into RAM together with initialized data (section .data). The RAM code is initialized at startup together with initialized data. If your code has interrupts, please disable them for the program operation, as the handlers may reside in the (now useless) Flash.

--

Tauno Voipio
tauno voipio (at) iki fi
Reply to
Tauno Voipio

Tosca Berisha wrote in news:gC55e.6392$ snipped-for-privacy@news20.bellglobal.com:

Yes, it can be. Generally speaking, we prefer to use seperate flash memories for data storage and program execution however. When we need to upgrade the software in the flash is when we load a utility into sram that in turn rewrites the firmware in the flash memory.

--
Richard
Reply to
Richard

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.