This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Using Cypress FX2 external RAM for code larger than 16k

I've scoured through both this site and at cypress to try and find out how to do this, but nothing seems to work. I have program code which is 27k in size, and the internal memory on the FX2 is only 16k; however, the FX2 allows using up to 64k via an external SRAM.

The difficulty I'm having is that when my program size goes over 16k, the Keil monitor stops responding, and my initial startup code that alights an LED never get exectued.

In the Project->Options->User tab of uVision4, I am running the hex2bix program with the -E argument and a memory size of 32k (my EEPROM is larger than that) to be sure. However, I don't think this program should affect the monitor/debugger's ability to run, nor affect my LED lighting code.

My thought was that the address space used by the Keil monitor (I'm using mon-ext-sio1-c0.hex) was being overwritten, but the Keil website says that the monitor uses this address space:

C:E800h — C:FFFFh Monitor ROM

Which I should be nowhere near, given that I'm only using 27k.

It sure seems like there's an option I'm missing or something, but when I comment my code down to 16k, things work well -- as soon as I cross that threshold though, nothing seems to work at all.

Thanks for any help!

Parents
  • First, thanks for the reply!

    When you mentioned the descriptors, that was my immediate thought. The way my code is set up now, I can easily switch between working code that takes up 14k, and non-working code that takes up 17k (the additional 3k has been verified on its lonesome.) When I load up the smaller code and step through it, the pDeviceDscr pointer in main.c points to 0x1300, but in the larger code, it points to 0x1400. That doesn't seem like a notable threshold to me, since it's still residing in the internal memory. However, just in case, I added a "cseg AT 0x1300" to the dscr.a51 file to try and force it to the working address. By stepping through the code again, I saw that pDeviceDscr did show at 0x1300, but it doesn't seem to have fixed the issue.

    As for the SRAM connection, this is on my own hardware, but it seems to be wired up correctly -- the Keil Monitor-51 is running in the extended space just fine.

    On the specification of code and xdata space, I'm using the SMALL memory model, with a Large Code Rom Size, and I'm also using the LX51 extended linker, since it produced much smaller code. Under the LX51 Locate tab (under Options for the Target) I have checked "Use memory layout from Target Dialog", and I've also Reserved 0xC000-0xFFFF for the Keil Monitor-51 address space.

    When I'm using the smaller code, I can specify the "Off-chip Xdata memory" to be starting at 0x3942 (my small code after compiling is 14658), and have a size of 0x11F5 (my xdata size after compiling is 4597) and things work out just fine. (This should also prove out that the SRAM is connected correctly) To leave room for larger code, I moved the start to 0x6000 and it continued to work well.

    However, trying these same settings with the larger code show it not working. I see the device disappear from the EZ-USB Interface window of the Cypress USB Console as expected, but my LED never alights, and when I look in Device Manager, it shows up as an Unknown Device. At this point the Keil debugger seems to have lost connection with the device as well.

    Since the device seems to be renumerating, but coming up as an Unknown Device, I keep thinking that there must be something going on with the program code and the descriptors are getting overwritten, but they're definitely in the internal memory (at 0x1400), and I'd think the linker would account for that.

Reply
  • First, thanks for the reply!

    When you mentioned the descriptors, that was my immediate thought. The way my code is set up now, I can easily switch between working code that takes up 14k, and non-working code that takes up 17k (the additional 3k has been verified on its lonesome.) When I load up the smaller code and step through it, the pDeviceDscr pointer in main.c points to 0x1300, but in the larger code, it points to 0x1400. That doesn't seem like a notable threshold to me, since it's still residing in the internal memory. However, just in case, I added a "cseg AT 0x1300" to the dscr.a51 file to try and force it to the working address. By stepping through the code again, I saw that pDeviceDscr did show at 0x1300, but it doesn't seem to have fixed the issue.

    As for the SRAM connection, this is on my own hardware, but it seems to be wired up correctly -- the Keil Monitor-51 is running in the extended space just fine.

    On the specification of code and xdata space, I'm using the SMALL memory model, with a Large Code Rom Size, and I'm also using the LX51 extended linker, since it produced much smaller code. Under the LX51 Locate tab (under Options for the Target) I have checked "Use memory layout from Target Dialog", and I've also Reserved 0xC000-0xFFFF for the Keil Monitor-51 address space.

    When I'm using the smaller code, I can specify the "Off-chip Xdata memory" to be starting at 0x3942 (my small code after compiling is 14658), and have a size of 0x11F5 (my xdata size after compiling is 4597) and things work out just fine. (This should also prove out that the SRAM is connected correctly) To leave room for larger code, I moved the start to 0x6000 and it continued to work well.

    However, trying these same settings with the larger code show it not working. I see the device disappear from the EZ-USB Interface window of the Cypress USB Console as expected, but my LED never alights, and when I look in Device Manager, it shows up as an Unknown Device. At this point the Keil debugger seems to have lost connection with the device as well.

    Since the device seems to be renumerating, but coming up as an Unknown Device, I keep thinking that there must be something going on with the program code and the descriptors are getting overwritten, but they're definitely in the internal memory (at 0x1400), and I'd think the linker would account for that.

Children