memcpy() don't work in S12X

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

memcpy() don't work in S12X

830 Views
everkimage
Contributor IV

My mcu is MC9S12X.

In my CAN driver executed by xgate,i use memcpy() to copy data to buffer.And in application layer,i use memcpy() to copy data from buffer.

At first,everything is ok.But after a while,in application layer,i cann't receive the data sended from pc.

Then i debug the program and find it's ok in CAN driver to receive the data,but when copy data from buffer to vars using memcpy,nothing happen!

This means sometimes memcpy() work,but sometimes don't.

I check the return value of memcpy(),nothing get change too.

Labels (1)
0 Kudos
3 Replies

715 Views
lama
NXP TechSupport
NXP TechSupport

Hi,

your description is a little bit confusing.

You use memcpy but you do not describe from where to where.

1) Xgate code copies data and they are processed in CPU

2) Xgate code copies data and they are processed in XGATE

3) CPU code copies data and they are processed in CPU

In the first case there could be issue from address point of view. There is difference how the CPU sees the RAM and how the Xgate sees it. Please look at attached memory map.

In this case you have to think about pointers conversion - depends on pointer type and placement. In order to understand it is good to step the code via ASM and think about what he code is doing. If you shares data only than it should be enough to put it into shared data section.

Best regards,

Ladislav

0 Kudos

715 Views
everkimage
Contributor IV

CAN driver executed by Xgate save the register data into CAN Data Buffer(direct address 0x2950).

CPU code copy CAN Data Buffer into temp variable(direct address 0x32CC).

Sizeof(CAN Data Buffer Item) = 0x0C.

memcpy() works at first,but after a while,it doesn't.

I don't know if the timing is fixed or not.

Code below make the system work,but i don't know why memcpy() not.

static void bytecpy(byte *pd, byte *ps, byte size)

{

   while(size--)

   {

      *pd++ = *ps++;

   }

}

0 Kudos

715 Views
lama
NXP TechSupport
NXP TechSupport

I am still not sure. The address 0x2950 does not exist at XGATE. However if I take it as a XGATE address converted to CPU and I will accept you are sure that the space is correctly shared and if I accept your pointers are correct then the issue I see in the sharing variables and access timing. (semaphores should be used in this case)

However, if you code works after you use own similar but not the same routine as MEMCPY is then you really should think about pointers and input parameters for MEMCPY function. The memory looks to be defined for near space only and there is either RPAGE or GPAGE pointer access used it will cause error.

I have prepared an example project which copies data from XGATE buffer to CPU buffer where info about placement is shared by pointer which is then converted from XGATE point of view to CPU address space to be CPU able to see it. All comments are part of the code. I have put trigger of the action to PIT interrupt which fills some buffer at XGATE and then it calls itself at CPU and copies data from the buffer filled at XGATE to a buffer used at CPU. (BTW, I do not understand why you do not use shared variable some buffer which can be copied to another buffer at CPU without any problems without pointers or can be directly used by both cores) Simple example is a part of the code where I use variable “diodes” to modify it by both cores and unaccepted simultaneous approach is avoided by semaphores.

I still see the problem. Your description is not correct.
The only default (RAMHM=ROMHM=1) direct addressable parallel NEAR (16bit address) spaces CPU and XGATE are:

 

CPU(adddress space-column F)                 XGATE(adddress space-Column M of the memory map)

4000-4FFF                                                C000-CFFF

5000-5FFF                                                D000-DFFF

2000-2FFF                                                E000-EFFF

3000-3FFF                                                F000-FFFF

 

So if the XGATE stores data (go through assembler to be sure) at XGATE NEAR address, for example, 0xE950 then the CPU is able to find them at CPU NEAR address 0x2950.

Moreover, are you sure about data consistency and you use semaphores to be sure the CPU and XGATE do not acces the same space at the same time?

I have attached an example which copies data from XGATE buffer to CPU buffer in the same buffer when the XGATE interrupt calls itself interrupt at CPU to copy data immediately after they are received. The code is based on the idea the buffers are placed dynamically by compiler. It means I do not placed them manually at given and specific address space.

Of course, you can perform the same by calling SW interrupt easily to ensure immediate data copy after they are received. (The easies approach would be to share the buffer between CPU and XGATE but in this case it is suitable to use semaphores to ensure data consistency)

If you want memcpy is correctly working then both spaces must be addressable by CPU in correct range. Because of this conversion of the XGATE pointer to CPU range is made for default RAM memory setup (RAMHM=ROMHM=0) and for condition both buffers (RAM and CPU) are stored in near memory labeled as shared memory in the prm file of the project as well as the pointers to a buffers are near.

(if you remap the memory by RAMHM and ROMHM then approach to convert pointers is similar)

I would like to suggest you to go through the code and think about addressing modes.

Memory map and pointers usage really requires to go through the assemebler code with some test projects to be sure you perform everything correctly and understand what you really do. This is not offensive expression, this is what I have also to do after years of experience because Murphy's laws are absolutely valid.

Best regards,

Ladislav

0 Kudos