This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

F28M35H52C: Passing arguments to a function that was copied from flash to RAM.

Part Number: F28M35H52C

Hello.

I am having problems with a function that is loaded in flash but executed from RAM. The thing is that when calling it, not all the arguments are correctly passed. I am not sure why but I know the problem is related to the fact that is run from RAM because when I loaded and run it from flash, it works fine.

The strange thing is that the function receives 3 arguments, all of them are pointers, but only one of them is wrong passed and it seems to be always the last one (I tried modifying the order and realized about this).

Looking for answers, I found this thread in which I am quiet sure the person who asked had the exactly same problem:

I am not concerned about all the things that have to be set to correctly run a function from RAM when it was loaded in flash. However, in my case it is not possible to use the ramfunc attribute because they do not fit in RAM (even though I use the shared one) so they can not be simultaneously placed in that memory. Depending on some inputs, I call different functions so they are copied there when it is necessary with copy_in(...) and COPY_TABLE variables.

Is there something extra that should be done to make functions call work correctly when it is used the copy_in mechanism to achieve RAM placement of some functions? I followed the document spraa46a in order to do this and it seemed to be fine, but when I added more arguments to functions, something failed.

  • Hi there,

    This sounds like a pretty interesting situation and one I have not seen before. I will do some digging here and see if I can understand what may be happening. I am also looping in a compiler expert as this seems like it is definitely an advanced topic.

    Thanks,
    Mark
  • Hi,

    I have been thinking on this and it got some feedback from our compiler expert. It doesn't appear that there will be any issue copying the function from Flash to RAM.

    Perhaps the values of the pointers that you are passing into the function are being overwritten prior to the function call. i.e. calling the copy_in function overwrites the memory location which the pointer is referencing.

    Have you been able to detect when the parameter "goes bad"? Observe the memory location of the pointer reference in the Memory browser of CCS before calling the copy_in function, and then after.

    -Mark
  • Hello and sorry for my delay. Regarding to what you said:
    "Perhaps the values of the pointers that you are passing into the function are being overwritten prior to the function call. i.e. calling the copy_in function overwrites the memory location which the pointer is referencing. "
    I do not think this is happening. I call the copy_in function at the beginning of the program, then I call malloc to allocate memory for the pointers and after that I pass them as arguments to some functions. Most of this functions can handle this correctly but not all. I finally "solve" this by passing just a pointer with the other pointers referenced by this one.
    "Have you been able to detect when the parameter "goes bad"? Observe the memory location of the pointer reference in the Memory browser of CCS before calling the copy_in function, and then after."
    I think I did not explain the issue correctly. The problem is not that the memory location is overwritten or somehow lost. The problem is that I pass a pointer to a function and the local variable that is supposed to have that value have a different one. But the memory location to which the original pointer references keeps its information correctly.
  • Hi there.

    It is challenging to picture what is going on here. I think I understand now. Please correct me if I am wrong:
    Simply stating the issue: When you pass a pointer to a function, the value that should be loaded into a local variable isn't.

    Can you step through the disassembly and watch the context switch? See if the right values are loaded into the CPU registers are being loaded correctly befor the function call and that the correct values are being loaded into the local variables at the beginning of the function. This could tell us exactly when the value gets corrupted.

    Does this happen on only one function?
    Does this happen on every call the function?

    You stated that that you "solved this by passing just a pointer with the other pointers referenced by this one", do you mean to say that you have found a workaround to the issue? If so, you have removed the malloc call and the issue has gone away?

    Thanks
    Mark
  • Hi there,

    Its been a few days since your last reply. I am going to go ahead and close this thread. If you still have additional comments or questions, please reject this resolution and post a reply with any additional information that will help with the debug.

    Thanks,
    Mark