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.

Tosca Berisha <tberisha@uucp.gov> wrote:
> Hi all,

> I am trying to erase memory blocks of the flash mem. above the code 
> sections. 

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.

Tosca Berisha wrote:
> 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.

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

Tosca Berisha <tberisha@uucp.gov> wrote in news:yNS4e.5366$6k4.655997
@news20.bellglobal.com:

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

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

Richard wrote:
> Tosca Berisha <tberisha@uucp.gov> wrote in news:yNS4e.5366$6k4.655997
> @news20.bellglobal.com:
> 
> 
>>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.
> 
> 
> 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.
> 

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

Tosca Berisha wrote:
> 
> 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?
> 

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

Tosca Berisha <tberisha@uucp.gov> wrote in
news:gC55e.6392$6k4.781464@news20.bellglobal.com: 

> Richard wrote:
>> Tosca Berisha <tberisha@uucp.gov> wrote in news:yNS4e.5366$6k4.655997
>> @news20.bellglobal.com: 
>> 
>> 
>>>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.
>> 
>> 
>> 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.
>> 
> 
> 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?
> 

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