7 Replies Latest reply on Apr 9, 2010 3:40 PM by xavier.de.donder

    CY7C64713 : accessing endpoint RAM directly

              I'm using the CY7C64713, I only need Endpoint0 and Endpoint1..   
      I would like to use the 4KBytes of RAM, available for unused endpoints 2,4,6,8 as regular data RAM. Is this possible?   
      It seems like I can use following chunks without problem :   
      I can't read/write correctly in the chunks   
      Why is this? How should I configure the unused endpoints (EP2CFG ... EP8CFG) in order to enable use of the complete block of RAM?   
        • 1. Re: CY7C64713 : accessing endpoint RAM directly
                  Correction :   
          accessible/usable blocks : 0xF000-0xF5FF and 0xF800-0XFDFF   
          unusable blocks : 0xF600-0xF7FF and 0xFE00-0xFFFF   
          • 2. Re: CY7C64713 : accessing endpoint RAM directly

            you cannot convert endpoint buffers to usable blocks... 

            • 3. Re: CY7C64713 : accessing endpoint RAM directly
                      Thanks for replying, Aasi!   
              Actually, I am already using most parts of the endpoint memory as regular data ram, this seems to work without problem. However I do notice that changing the endpoint configuration makes some parts of the memory unusable. I just can't find any logical relation between endpoint configuration and "freely usable" memory, and I wonder if there is a configuration which enables to use all memory (without using any endpoint functionality). I guess you are right, I might be using "unsupported" functionality which is not a wise thing to do - my current design unfortunately has grown so much that I'm in desperate need of extra data memory without doing a hardware redesign...   
              • 4. Re: CY7C64713 : accessing endpoint RAM directly
                        See Chapter 8.5 of the Technical Reference Manual.   
                Endpoint buffers are always at least double-buffered. The problem you have uncovered is that in order to accurately support double-buffering, you only get to directly access half of the buffer.   
                So, for instance, Endpoint 4's buffer space goes from 0xF400-0xF7FF - 1024 bytes. Because you have EP4 configured as double-bufferd 512-bytes, you only get to access 0xF400-0xF5FF. The FX2 manipulates the other half of the buffer to provide the appearance of double-buffering.   
                You can try setting the EPxCFG bit 7 to 0 (the "valid" bit). This may or may not affect the situation.   
                • 5. Re: CY7C64713 : accessing endpoint RAM directly
                          Thanks andrewsobotka, you are spot on!   
                  With this info of chapter 8.5 in mind, I had another look at the ram organization (fig.1-16 of the same manual) for the 12 possible configurations. There are a few configurations, which allow the CPU to access 0xF000-0xF3FF (EP2 double buffered 1024 bytes) and 0xF800-0xFBFF (EP6 double buffered 1024 bytes). Same for 0xF400-0xF5FF (EP4 double buffered 512 bytes) and 0xFC00-0xFDFF (EP8 double buffered 512 bytes). The 2 remaining memory regions are never used as "primary" memory in a double- or quad-buffered config. This must be the reason why I can't access exactly those 2 chunks, even when all endpoints are disabled ("valid" bit set to zero). Thanks for opening my eyes !   
                  • 6. Re: CY7C64713 : accessing endpoint RAM directly
                            You could also try configuring EP2 as quad-buffered 1024-byte and see if the memory opens up for you. Try doing it with the valid bit set and clear. It might be the case that quad-1024 will open up everything for access, and clearing valid will ensure that no activity causes the buffers to flip.   
                    • 7. Re: CY7C64713 : accessing endpoint RAM directly
                              I believe I tried that before, but to make sure I retested this configuration (EP2 quad-buffered 1024) - it doesn't work. Which actually confirms what you pointed out earlier: I can only access the "first" memory chunk in a dual/triple/quad buffered configuration.