We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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.)
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.)