Problem with Memorymap

[rinfo9]

Posted on December 03, 2004 at 17:13

Problem with Memorymap

[rinfo9]

Posted on May 17, 2011 at 12:03

Hi,

we're doing a redesign of an existing environment and are planning to use a uPSD32xx. I got problems with implementing the mem.map. It shoulkd look like this: Normal Operation-Mode (external Dipswitch == 1) Code Xdata FP0: 0x0000-0x7FFF FP(Pageselect): 0x8000-0xFFFF (R) FP1: 0x8000-0xFFFF Peripherie: 0x7800-0x7FFF (RW) SRAM: 0x0000-0x3FFF(max) (RW) In Bootloadermode (external Dipswitch == 0) CODE XDATA CSBOOT0: 0x0000-0x1FFF FP(Pageselect): 0x8000-0xFFFF (RW) CSBOOT0: 0x2000-0x3FFF Peripherie: 0x7800-0x7FFF CSBOOT0: 0x4000-0x5FFF SRAM: 0x0000-0x3FFF(max) CSBOOT0: 0x6000-0x7FFF don't care: 0x8000-0xFFFF I did this design easily on a standard-pal but i'm really busted with this PSDsoft Express thing I'd be very glad if anybody of you knows how to do this an tells me how.

[jdaniel]

Posted on May 17, 2011 at 12:03

H-Ray,

Like many problems, there's more than one way to solve this. What *I* would have a tendency to do is put this under software control. That is, I would write some startup routine and have the linker locate it to the SAME EXACT address in both Main and Boot Flash. I would have this routine make the determination (by examining a normal 8051 input pin with the switch connected) of what page to startup in. Then I'd just have it do the switch and continue. The easier way (although the one with which I admittedly have less experience) is (as you may be suggesting) to let the CPLD handle it for you. Basically, in your PSDSoft project, you'd define the pin with the switch connected as a CPLD input and give it a descriptive name (I'll use ''signame'' here). Next, where you're defining the memory map, you'll notice there's a field for ''Logical AND of signal qualifiers.'' You could then throw ''signame'' into the fields for one bank and ''!signame'' into the other bank's pages and it should handle things for you. I suppose depending on what you're doing, you might need to look at prop delays, etc. to make sure you can't get into a state where the memory doesn't swap / respond quick enough for the bus, but with any reasonable clock speed, I'm guessing that's pretty unlikely. Hope that helps.

[rinfo9]

Posted on May 17, 2011 at 12:03

thanx for reply,

my problem is not the switching of the two modes itself, the main prob is the memorymap in normal-mode. unfortunately the formatting of my previous message failed, so you could not see what the map is supposted to look, so i just write (quasi)equations for the chip-selects... fs0 = (Page==0) & (8000 <= Address <= FFFF) & _psen // for xdata-access # address < 8000 & !_psen // for code-access fs1 = (Page==1) & (8000 <= Address <= FFFF) & _psen // for xdata-access # address >= 8000 & !_psen // for code-access fs2 = (Page==2) & (8000 <= Address <= FFFF) & _psen // xdata-access only ... fs7 = (Page==7) & (8000 <= Address <= FFFF) & _psen // xdata-access only the csiop and sram will be mapped anywhere in the lower 32k of xdata. so we have 64k-codememory, made up of fs0 and fs1 and 32k of xdata-flash of any wanted page. in my opinion this should work, but it does not. the curious point is: when you set the primary-flash to be seen as ''code-mem only'' at boot-up, the test-app starts running. as soon as you set bit VM.4 (to enable fs_OE also in xdata ) the proggy crashes. when you set ''code- and data-mem at bootup'' the app won't even start. i got a statement from a fae that says: it's not a good idea to use _psen, _rd and _wr in chip-select-equations. (he gave me no reason for that) I'm wondering why these signals are inputs to the DPLD when one may not use it? the only thing i can think of, is that this is a problem with accesspeed. i use the demoboard, running on (?) 32MHz. [ This message was edited by: H-Ray on 03-12-2004 21:53 ]