Hi,
Once upon a time, I sent you a memory map. You should now understand which core uses which addressing mode and how it accesses data and code.
CPU runs on PPAGE_OFFSET, but data is usually read/written using GPAGE_offset to simplify access.
XGATE can run from either flash or RAM. Before it can run from RAM, it must be copied from flash to the corresponding memory space. If you want XGATE to run from flash, you need to configure this during project creation-then no copying is required.
What I suggest is always to introduce code in each module by correct memory placement…
For example
#pragma CODE_SEG DEFAULT
#pragma DATA_SEG DEFAULT
#pragma CODE_SEG XGATE_CODE_FLASH
#pragma DATA_SEG SHARED_DATA
#pragma DATA_SEG XGATE_DATA
For the copying process (if used-I'm not going to check it), I would recommend using GLD/GST instructions to easily access the global memory space. As shown in the memory map, only part of the RAM is accessible for data using 16-bit addressing (from the CPU's perspective). To write to the part of RAM that is not visible via 16-bit addressing, you must use GPAGE or RPAGE addressing modes. However, when XGATE is running, it sees the entire RAM using 16-bit addressing.
Of course, even if the code runs from flash, there can still be a copyToRam function that initializes variables for both the CPU and XGATE.
I strongly suggest always using a simulator or debugger for testing to better understand the behavior. It's essential to test different addresses-meaning within the same address space but using different addressing modes-in the memory window to verify whether the same content is visible across them.
Frankly, I am currently creating my hobby project at XDT512 and also have to debug a lot to be sure whether everything is where it is expected to be and result are as expected. Also warnings are important to read. I put display function to xgate a call them by swi from cpu. In order to avoid mistakes I always use integers as variables (xgate can make issue with arrays, structures because char is not good variable for it). I had also had to create conversion functions for pointers .. can be seen in conversion.c. As well as I used specific approach to init input parameters passing to xgate from cpu…you can see for example LCDcSetup(….), I call at CPU, which fill specific structure which is then used by void LCDxSetup(tUI setup) after the data set is prepared in the module lcd_comman_wrappers.c and the xgate is launched by SWI after data preparing. Of course there could be some amount of shared data prepared and different approach used but this is the way I used to pass parameters to the xgate functions from cpu.
I do not want to confuse or scare you. I want only to say the more combinations and expectation the more issues and more complex tasks to solve. After initial effort everything will be more easy and clear. Everything can be done easily or complex. I had LCD module for cpu and wanted to put it as easy as possible to xgate and I used this solution. It can be seen as useless because XGATE was intended to be used for small fast task. In this case I wanted to offoad cpu from long sending data tasks.
Currently I also have some bugs in it but going step by step and this is what I suggest also to you.
The S12X device are so simply that you can fully delete all files generated by compiler and simply load stack as a first instruction of you code and then to have everything under your control.
Best regards,
Ladislav