/PSEN access to primary Flash

[wek2]

Posted on November 16, 2005 at 11:28

/PSEN access to primary Flash

[wek2]

Posted on May 17, 2011 at 12:09

I have a uPSD3212C with

fs0 0x0000-0x3FFF fs1 0x4000-0x7FFF fs2 0x8000-0xBFFF fs3 0xC000-0xFFFF csboot0 0x8000-0x9FFF csboot1 0xA000-0xBFFF rs0 0x0000-0x07FF csiop 0x0800-0x08FF If I jump to 0x8000 where I have the same program in both primary and boot flash; then I set VM to 0x16 (both the primary and the boot flash active for /PSEN and the primary active for /RD), reading the 0x0000-0x08FF area using MOVX yields the content of RAM/IOP, that's OK. But if I read the same area using MOVC, it yields garbage (more precisely, it returns the low byte of address, so it looks like the primary flash CS+OE is NOT active for that area). Can anybody explain me, why??? Jan Waclawek

[jdaniel]

Posted on May 17, 2011 at 12:09

Wek,

Clearly Kubrt misunderstood what you were trying to tell him about your situation. The priority scheme is only important if you have a given control line (RD, WR, PSEN) mapped to TWO different types of memory at an address and page into which you have both these types mapped. That said, that isn't your situation. You have PSEN set to access either main flash or secondary flash, but it looks like from 0x0000 - 0x08FF the ONLY thing you actually have mapped is primary flash, so there shouldn't be any confusion. Here are a few preliminary questions: Have you checked that you're on the right page? You list your memory map, but is this constant for all pages, or do you have some sort of paging scheme that moves things around? That's about the only thing I could think of that could cause this behavior. You're right that somehow you're not getting a chip-select on the main flash like you expect. Here's another question (and this isn't meant to be an insult.. I don't know how much 8051 stuff you've done before): Are you clearing ACC before you use MOVC. Since it actually uses the DPTR incremented by A, you could accidentally access the wrong area. Have you tried using MOVC on different ranges within 0-8FF and had the same result? Finally, are you doing flash programming anywhere within your code? If you've gotten the main flash into a state where it's expecting programming commands, I believe it can behave ''strangely'' when you try to do other things if it hasn't been reset yet. Hope some of that is somehow helpful.

[wek2]

Posted on May 17, 2011 at 12:09

OK so you claim that the priority scheme applies on the output of DPLD, regardless of /PSEN, /RD, /WR state and VM setting?

This is obviously not true, as it would mean that no flash is accessible between 0000-08FF as data nor code memory; in other words, the uPSD would not run the code in flash at all as the reset vector is at 0000...The truth is, troubles start when the VM register is set to other than default value, so there IS some relationship in between VM and priority scheme. Why on earth you cannot pulish the whole logic, so the user could figure out how is it really working, instead of that vague triangle...? (please add this to my complaints on documentation in the other thread).Jan WaclawekPS. What do you mean by ''XMOV''?

[wek2]

Posted on May 17, 2011 at 12:09

Phaze,

This is going to be a long story... Please be patient.First, you can judge my '51 knowledge yourself - please have a look at my homepage (link in my profile here), some of my hobby '51 work is there.Now, I tried to describe the problem in as simple way as possible, although I found out what's on in a harder way. I started a project with the uPSD3212C last week, having some experience with '51 PSD813 before (I took over an older project). I like the features of the chip and they fit the requirements of the present project. For a start, I used the simplest template memory map offered by PSDSoftExpress - the same as I described above, no paging. Soon I found out that the way to program the chip using PSDSoftExpress is clumsy, so I decided to write a bootloder of my own, compatible with the P89V51RD2's bootloader's protocol, to be able to (ab)use esacademy.com's FlashMagic as the PC-side software.

[wek2]

Posted on May 17, 2011 at 12:09

My idea was to (upon reset with a certain pin held low) enable both flash at the very beginning of the program (which naturally was located in the 0-8FF area), then jump to 8000h, where the bootloader itself would reside in the secondary flash only. This scheme failed, the chip stalled - after some tests and experiments I found out it stalled at the moment I wrote 16h into VM. So I moved the ''switching'' into the area of 8000h and burned it both in fs2 (mapped at 8000h) and the boot flash - this worked. Then I implemented the bootloader itself and a dump - movx and movc - of the area 0-8ff revealed what I described above.

Just a note, the ''low address readback'' was not preceded by any flash write operation. But I later tried deliberately to make an invalid flash operation (write 0 to 1) and the dump read all the same value until flash reset instruction issued - no surprise, it returns the ''error flag'' repeatedly, reading any address within the flash sector. Finally I succeeded and the bootloader now works - also implementing a paging scheme - but that's an another story... I would be happy if you would try the same and perhaps confirm (or not) my findings. Don't get me wrong, I don't think this is a flaw, I am just pointing out that without a proper, clear and complete documentation, this - otherwise nice - chip gets slightly unusable and the obscurity of its internals will repell less determined developers from using it. Jan Waclawek PS Sorry for the multiple post, using a pda and it doesn't allow to submit a bigger chunk of text... [ This message was edited by: wek1 on 15-11-2005 14:02 ]

[wek2]

Posted on May 17, 2011 at 12:09

I played further with the configuration and VM register and found out the following: the problem is associated with /RD access enabled in VM register. When both RD and PSEN access is enabled for any flash, in the area where it overlaps with RAM and IOP when reading code (PSEN access) the result is the low byte of address. This applies for both flash separately.

The fatal consequence of this fact is, that if somebody choses in PSDSoftEpxress the primary Flash to be both Data and Program at powerup (=> the VM register default setting at reset (*)) and the memorymap from the template as above, it won't start the user program at all... Jan Waclawek (*) an another item to the documentation - it says the VM register can be defined in PSDSoftExpress but it took me a while to find out, where... [ This message was edited by: wek1 on 15-11-2005 14:24 ] [ This message was edited by: wek1 on 15-11-2005 14:25 ]

[jdaniel]

Posted on May 17, 2011 at 12:09

Jan,

Wow... good find, although something doesn't entirely jive with it for me. I had my application setup to have primary flash in both program and data space at startup (and I also have my RAM mapped from 0x0000-0x7FFF) and my program starts up just fine. Also, while I didn't create a bootloader compatible with FlashMagic, I DID write an IAP bootloader for my system. I used the paging method though, so it doesn't compare well with what you did (and also I'm using the uPSD3254). Here's a final question (which is probably a moot point), you're not using an emulator, are you? I have used both the Manley emulator for uPSD and the Nohau and they both use a bond-out chip that exhibits a problem similar to this. Just a wild guess.

[wek2]

Posted on May 17, 2011 at 12:09

Phaze,

Thanks for sharing your experience. No I am not using an emulator. Just one thing, if I understand your design well, you are booting into the secondary flash, so if you don't have both RD and PSEN access enabled for the secondary flash at boot time, you won't have the described problem. Could you please switch on both types of access for the secondary flash at powerup and try it so? wek