Hi All,
I am working with a uPSD33xx and the Keil C51 toolchain.
I am trying to produce a custom bootloader which is capable of IAP but I am having problems controlling flash.
The memory map of my application basically has CSBOOT0->3 mapped into 0x0->0x7FFF. This is where the bootloader program will reside. FS1->FS7 are mapped at 0x8000->0xFFFF on pages 0->6 with FS0 being mapped at 0x0->7FFF || 0x8000->0xFFFF on page 7.
(RS0 is at 0x0->0x&7EFF and CSIOP is at 0x7F00->7FFF)
So what I want to do is:
1) Bulk erase main flash;
2) download a new progam via ymodem
3) program the new image into main flash and execute.
I cannot seem to erase main flash.
Prior to sending commands to the flash array I am setting-up both the VM register (to 0x16, default is 0x06) and also the page register (to 0x00). So with these two settings I am expecting to have /RD /WR access to main flash at page 0 which should activate FS1 when I access any address in the range 0x8000->0xFFFF. Does that sound OK?
When I setup as described above and take a look at address X:0x8000 I see all FF's (erased flash?) - I am assuming this is correct as main flash should now be accessible as XDATA - but when I enter the bulk erase command sequence (to addresses 0x8AAA and 0x8555) I do not see any change in the values at these memory locations. I am trying to read them back via the debugger - should I be able to see them change in this way? Once my command sequence is complete and I begin to poll for status the value read from address 0x8000 (should be accessing main flash) is 0xFF and so the status bit is already set.
Something is not quite right here!
These are the chip select equations as output from the PSDsoft tool:
========= Equations =========
DPLD EQUATIONS :
=======================
fs0 = (!pdn & !a15)
# (!pdn & pgr2 & pgr1 & pgr0);
fs1 = !pdn & !pgr2 & !pgr1 & !pgr0 & a15;
fs2 = !pdn & !pgr2 & !pgr1 & pgr0 & a15;
fs3 = !pdn & !pgr2 & pgr1 & !pgr0 & a15;
fs4 = !pdn & !pgr2 & pgr1 & pgr0 & a15;
fs5 = !pdn & pgr2 & !pgr1 & !pgr0 & a15;
fs6 = !pdn & pgr2 & !pgr1 & pgr0 & a15;
fs7 = !pdn & pgr2 & pgr1 & !pgr0 & a15;
csboot0 = !pdn & !a15 & !a14 & !a13;
csboot1 = !pdn & !a15 & !a14 & a13;
csboot2 = !pdn & !a15 & a14 & !a13;
csboot3 = !pdn & !a15 & a14 & a13;
csiop = !pdn & !a15 & a14 & a13 & a12 & a11 & a10 & a9 & a8;
rs0 = rs0_0.FB;
jtagsel = !_reset;
INTERNAL NODE EQUATIONS :
!rs0_0 = (a15)
# (a14 & a13 & a12 & a11 & a10 & a9 & a8)
# (pdn);
PORTB EQUATIONS :
PORTC EQUATIONS :
PORTD EQUATIONS :
If anyone can help me here I would very much appreciate it.
Regards
Andy
Andy,
I'm not sure I entirely understand. You must remember that 0xFF IS the erased state for flash memory (in general) as all that happens during programming is some bits are set to zero and others are left unchanged. As far as the polling sequence showing it being erased immediately, it's not impossible that that happens if the flash bank you're accessing has NEVER been programmed. Try programming something into that flash region (like a fixed sequence of 0x01 0x02 0x03, etc.). THEN try erasing it. If it goes to all 0xFF's, you've succeeeded.
As far as what you see in the debugger, I wouldn't expect to see any changes in those locations until the command is complete (that is, doing something like *(unsigned char *)0x8555 = 0x12; wouldn't actually change the value. They're just being interpreted by the internal control logic of the flash chip.
In my opinion, the best thing would be to intentionally NOT have the debugger access these memory locations except BEFORE and AFTER you execute your commands. The accesses to the memory that the debugger is doing might adversely affect the instruction sequence (that is, the chip might see a memory READ in between your two writes and cancel the operation).
-Jay Daniel
All working now - no probs.
Mr. Andy,
Well im here to ask you a favor? pls. Can u help me how to improve or to put extra features in flash? can u give me some solution,suggestion or advice for that.... i know u r excellent in flash.. hoping 4 ur reply.. thanks LEE of the Philippines