I have 2 off Atmel AT49BV322D devices in my design to provide a 32 bit wide memory. I am using the flash Memory Download Setup option AT49xV32x Dual Flash with address range set to 80000000H - 807FFFFFH. The device size is reported to be 8M (although the device is actually 2M * 16). My design has LPC2214 address lines A2 - A22 connected to the AT49BV322D address lines A0 - A20. I have used a flash.ini file to configure the BCFG0 and PINSEL2 registers.
When I try to download I get the Erase Failed! message.
Am I using the correct flash memory driver? Should I add another AT49xV32x DualFlash to the download setup? Is there an updated version of this driver with the correct memory size?
AT49xV32x Dual Flash algorithm is the correct one and only one is required.
AT49xV32x size is 2M*16 or 4M*8. When two are used to provide 32-bit wide memory the total size is 8MB.
A proper flash.ini is required which will configure the external memory controller. Can you show the script file you are using?
Hi Robert, here is my Flash.ini :- FUNC void Setup (void) {
_WDWORD(0xFFE00000, 0x20003CE3); // BCFG0: Flash Bus Configuration
_WDWORD(0xE002C014, 0x0F814924); // PINSEL2: CS0, OE, WE, BLS0..3 // D0..31, A2..23, JTAG } Setup(); // Setup for Flash
Another thing I have found is that within the AT49xV32x Dual Flash C source file (as supplied by Keil....\Keil\Arm\Flash\AT49xV32x_2\FlashDev.c) the polling checks are made to the status bit 6, whereas the Atmel data sheet refers to bit 7 to poll for completion of the program word. I have made my own version of the algorithm to check bit 7, and this now completes the erase chip and erase sectors which are performed at the start of the Download flash. I am now able to complete the Download flash, but it appears to only be writing to addresses with A0 = 0, when A1=1 then the location is not programmed. As you can see I am getting there slowly. But I have only been able to get this far by creating my own version of the supplied algorithm (checking status bit 7). This is what made me suspicious that the supplied algorithm had bugs in it.
Have you been able to succesfully use the Keil supplied algorithm?
regards John
Robert, I forgot to say that upon completion of the download then after the verify phase completes I get the following message for all locations where bit 2 of the address=1 (which corresponds to the real A0 signal due to the 4 bytes written per memory word) Contents missmatch at: 80000004H (flash=FFH Required=33H) ! this is the same format message for all the other locations with bit 2 set.
locations 80000000H to 80000003H ,and alike, do not report errors (i.e bit2 = 0)
AT49xV32x Dual Flash algorithm has been successfully used on different targets (example: Phytec phyCORE SBC with LPC2294).
<the polling checks are made to the status bit 6, whereas the Atmel data sheet refers to bit 7 to poll for completion>
The mentioned algorithm uses Toggle Bit algorithm for completion and the Atmel User Manual clearly states that I/O6 (bit 6) is used for this.
Let's first assume that the original unmodified algorithm works and check the HW and the initialization script.
Has the HW already been verified (all connection correct in schematics and actual PCB)? Is the address/data bus correctly connected? How are nOE, nWE connected? Is the Flash nBYTE pin connected to logic high?
After further reading of the Atmel data sheet I now realise that the Keil algorithm was using the Toggle mode for polling (which uses status bit 6 to check for completion status). The use of the Toggle mode requires that the Set Configuration Register is set to mode 01. I have now set the status bit checking to use bit 6 as originally supplied in the Keil algorithm. I apologise for thinking that there was bugs in the supplied code, and I now realise that the reason that my mods apparently partially worked was that my memory was trying to operate in the Mode 00, which used bit 7 for status polling.
I have now been able to reliably program my flash memory after making 2 mods to my programs. It appeared that my memory was'nt getting set to the Toggle mode after power up (the Atmel data sheet says that the default mode is 00 upon power up or reset). I believe that the Keil flash program is trying to set this mode to 01, but maybe I have a timing issue that prevents the memory from being loaded with this value.I have therefore added the following initialisation code as part of the Init(..) function in the FlashPrg.c algorithm
int Init (unsigned long adr, unsigned long clk, unsigned long fnc) { base_adr = adr; // set Configuration register to 01 i.e TOGGLE mode M32(base_adr + (0x0AAA << 1)) = 0x00AA00AA; M32(base_adr + (0x1554 << 1)) = 0x00550055; M32(base_adr + (0x0AAA << 1)) = 0x00D000D0; M32(base_adr + (0x0AAA << 1)) = 0x00010001; return (0); }
The values assigned in my Flash.ini file are now:
_WDWORD(0xFFE00000, 0x20001062); _WDWORD(0xE002C014, 0x0F814924);
All is now working fine...thank goodness:-)
Fortunately the H/W connections were all OK. My usual fault finding always checks these signals before checking my code...I'v learrnt from experience to always check my hardware connections first...lol
Thank you for your advice and help.
I'm happy that it works now.
However there are still some points which are not clear:
Keil algorithm uses Toggle on I/O6 which is always available regardless of Configuration Mode (Mode 00 or 01). The algorithm doesn't touch the Configuration register (the default value after reset is 00). Therefore changing Configuration Mode to 01 should not be necessary.
Also I see that in the latest Flash.ini you have changed the configuration of BCFG0 (Bus Configuration for Bank 0). Now RBLE bit is 0 (before it was 1). So maybe this was the actual problem. I would need to see the schematics of the CPU <> Flash connection to be able to judge this.
Anyway you can ignore the above remarks if you are happy that it works or you can look further into this to clarify the remaining questions.