psoc3 c51 error: different memory space

[WaMa_286156]

I am attempting to port a project from PSOC5 to PSOC3, using FreeRTOS.   (I started with the SDCC Cygnal port)

This work is being done due to parts shortages.  We need to keep shipping product if we want to stay in business.

Some Cypress parts are 14 months or more before delivery.  (I assume Infineon parts are more important than Cypress parts, at least for now.)  I am trying a stopgap solution if it is possible.   It would be nice to know if the red headed stepchild is going to be buried in the back yard or not, so other designs can be started.

I am still a little fuzzy on the 8051 and the implications of the extensions that Cypress put in place to allow for 24 bit data pointers (DPTR0 and DPTR1).  If this were just assembly, I think I would be ok.

Yes, I know that RTOS for 8051 is a bad idea, etc. etc.  However, the ARM PSOC5 is running around 50mhz and doing fine. The time domain of reporting is flexible and can vary once the data is captured.  The hardware slid into the PSOC 3 quite easily, although I had to give up a SAR monitor that was not really necessary for operation.

In the port.c file, I have come across a compile error for the Keil compiler, and I don't understand what it is telling me.  A google gave no good information, the error # is a generic one for many problems.  The line is as follows:

/* Used during a context switch to point to the next byte in XRAM from/to which
a RAM byte is to be copied. */
static xdata  StackType_t * data pxXRAMStack;

   The StackType_t is uint8.

 The xdata is external data (8 k in this particular PSOC3 processor, 64 k flash).   The data is the internal 256 byte data area.  The comment explains the purpose.

The error is :

ERROR: ..\Source\portable\Keil\psoc3\port.c:61: 'pxXRAMStack': different memory space

How do I handle this error?  I am sure it is some stupid misunderstanding on my part.   The sad thing is it reported to work with the SDCC compiler.    I have read parts of the Keil documentation, an 8051 book, the TRM for the PSOC3, and I am still missing what the error is trying to tell me.

According to the Cx51 User's Guide: Generic Pointers, this is a pointer stored in data that points to xdata.  So why the error?

Should/Could the SDCC compiler be used for PSOC Creator, and allow for debug, etc?  If so, some things might go easier, or might not.

Thanks!

[ncbs]

Hi @WaMa_286156,

Check the below thread, it might be of help:

https://community.infineon.com/t5/PSoC-5-3-1/FreeRTOS-for-PSoC3/m-p/186838

Regards,
Nikhil

[WaMa_286156]

Thank you, but that old thread ended in failure in 2011.

However, if you go to 

https://github.com/wmaxfield/FreeRTOS-Minimal/tree/master 

you can download a working port of FreeRTOS to PSOC5.  This is a "minimal" port, configured for the CY8CKit-059, with blinking light task, USB Serial port task, and the UART attached to P12[6],P12[7] are included.  It tells you how to use the KitProg3 debugger as uart, and explains installing the USB Driver in Windows 7.

Still no answer on the 8051 errors.

enjoy!

[WaMa_286156 · Accepted solution]

I think I have found the answer.  It took a lot of experimentation.

The documentation for the Keil compiler is more related to NXP/uVision processors and systems, and not the Cypress PSOC.

It looks like the default memory model for compile under PSOC 3 is Large.  However, the default location of the data variables  is in the "data" area (small).   The Cx51 compiler documentation says that generic pointers will work in one location, but in other locations, the generic pointers are only generic for certain data areas in the 8051 (NOT xdata).

So, the compiler complains, because the compiler is not doing what the documentation indicates in one section, but it is doing what the documentation indicates in another section.  This warning probably should be an error.

The solution for the problem is to:

1) (depending upon xdata ram available for your particular device) Point all variable pointers to CYXDATA, and make sure all pointers use CYXDATA as a qualifier, like this:

#include <cytypes.h>

char CYXDATA *ptr;

If you do it that way, it can be compiled on a PSOC 5LP with no problems (future porting strategy)

2) All variables are put in 'data' by the compiler as a default, even in the large mode.  Force them to be in xdata like this:

char CYXDATA myVar;

  Of course, for faster access, you can change the CYXDATA to CYDATA, but be careful pointing to it.

  I know that the PSoC Creator is almost PSOC Cratered, but Cypress could possibly save some licensing fees in the future by moving to the SDCC for the compiler underneath.  

enjoy!