Anyone have a simulated peripheral DLL for an AMD-compatible flash memory that they'd be willing to share? (Is there a library of such add-ons for the uVision simulator? I found the app note (154) describing how to write DLLs, but the download area didn't seem to have any -- of any sort, so perhaps I wasn't looking in the right place.)
The zip file contains several example projects. http://www.keil.com/appnotes/docs/apnt_154.asp
Someone posted an LCD simulation recently - try a Search
Hi, can you post the device information about the flash device ?? I will show if a simulation is possible and not too difficult for me.
To be specific, I have an Atmel part, the AT49BV320. http://www.atmel.com/atmel/acrobat/doc1494.pdf Lots of manufacturers are (more or less) compatible with the AMD flash command interface (e.g., the AMD29LV320D), so perhaps this data sheet is useful. http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/23579b1.pdf As another example of similarities and differences, the Toshiba part (TC58FVB321FT): http://www.toshiba.com/taec/components/Datasheet/TC58FVTB321FT_XB_E.pdf Essentially, the chip just looks for special patterns of values on the address and data lines over a few bus cycles to signal a command. For example, to write a value of 0x00 to an address "addr", you might do something like:
// program a byte of flash *(0x555) = 0xaa; // bus cycle 1 *(0xaaa) = 0x55; // bus cycle 2 // any address in the right sector will do; but addr has to be in its own sector *(addr) = 0xa0; // "program" command // "addr" is the actual address to write *(addr) = 0x00; // actual write
Thanks, I will check it this weekend and give you an answer. Michael
Hi Drew, I have found the following problem: If you program the flash device and make a reset from the simulation (e.q. reset button) the program sequence from the flash will be lost. Is this a problem for you ? Also the simulation will work a little bit slower. Which memory ara do you use for the flash? Do you use a banking mechanism ? With ports are an additional latch ? Michael
It's not a problem if a reset interruts flash programming. (In fact, that's probably appropriate, since a real reset would do the same thing; reset interruptions could be a useful feature to test how well the flash update routines tolerate unexpected restarts.) We're mapping the flash to xdata starting at 8'0000H. Our CPU has 24-bit DPTRs, with the upper 8 bits in SFRs 0x93 (DPX for DPTR) and 0x95 (DPX1 for DPTR1). That is, it has extended, dual data pointers like the Dallas 320/390. So from C, access to the flash is via a "far" pointer with the DPX registers supplying the upper 8 bits. (The actual ASIC uses only 20 bits of address bus, so not all the bits are actually brought out to the memories.)