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.

MSP430FG6426: Nested Function parameters handled from Registers are not restored after a function call

Part Number: MSP430FG6426

Dear Team,

I have a function (Function_1) that inturn calls another function (Function_2) and while the final leaf function is executed and return back to the caller function, the local function parameters are not restored. Manwhile i have some ISR's also running in parallel (Timer, SPI, ADC..)

I notice that the function parameters are stored in the register and thats where the problem comes in. If i try to move these parameters as global variables then i don't see a problem, but i cant do this now for my complete software and want to fix the problem at its root, as i see that the below example is a valid C usecase and expect this to work.

I do not notice this issue in my other smaller projects but when i start build big ones, and in my project case i reached 31kb of flash size, and now i start seeing this issue for the codes that earlier worked without issues.

Could you please help here if i can do something to get my project back running without this issue ?

CCS version - 9.2.1

Example:

Function_2(uint32_t Param3)

{

   // Do something with Param3

}

Function_1(uint32_t param1, uint32_t param2, uint32_t param3)

{

  //Note: The compiler saves these parameter values in the Register

  for(i=1; i<10; i++)

  {

     param3 = param3 + param1 + param2; // Some calculation on parameter 3 variable based on param 1 and 2

     Function_2(param3);

     // Note: After this Function_2 is returned, the original values of the Param1,2,3 are not restored leading to malfunction

  }

}

main()

{

  while(1)

  {

   Function_1(1,2,3);

  }

}

  • I can't really tell anything from your code skeleton.

    Registers are grouped into caller saved and callee saved. This gives each function a set of registers it can use for its operations without worrying about saving and restoring them. C compilers are very good about observing this (it is possible to circumvent this as gcc has a "naked" function attribute) so your problem is almost certainly due to something else. But without the offending code, it is impossible to say what.

  • I agree with David that can't tell anything from the posted code skeleton.

    Are you able to either:

    1. Post the complete project which shows the problem.
    2. Post the information in How to Submit a Compiler Test Case if you can identify an issue in the assembler generated by the compiler.

    Since an interrupt handler will have to save registers on the stack it is possible the issue is caused by stack corruption, e.g. due to insufficient stack space or the program writing to an invalid pointer.

  • Dear Together,

    Thanks for your response. I understand that skeleton code does not help to foresee the issue. 

    I have attached my project here where i started seeing this problem with the memory IC handling (W25Q) which worked before when the project was too small and now when the project is nearly at the end of completion with lots of stuffs added i see this corruption issue happening randomly. I notice it when my code gets such at infinite loops and notice that the local pointers are corrupted after return from function calls and not restored as expected.

    I see this at 2 cases when i call this function from main "MEM_CalcFreeSpace(MEM_STORAGE);" and "void SPIFlash_ReadData(char* dat, uint16_t len)" called nested from "W25qxx_WritePage". And once this happens the Interrupt ISRs are also not executed as well until i make a reset. 

    This is happening now when i made my project bigger with more functionalities called from main() [Display, external USB, Keypad...]. The same worked well when i just had a small project with the W25Q memory driver and some small features alone.

    i also see that the stack size has reached 100% (116 bytes) which i am not sure if this could be an issue too. I tried to increase the default stack size to 256bytes but still i see the same here.

    I have a fear that such random corruption cases would happen during production and would really help if you can hint me something based on your experience here to fix it right. 

  • Sorry missed to attach the project. I have copied the complete project on my drive that can be accessed here.

    https://drive.google.com/file/d/1gk1Cy0cFmULcUVJQT5eiVQMrwxHeVKEF/view?usp=sharing

    Thanks again for your great support

  • Keep in mind that setting a stack size in no way limits the growth of the stack. You could do that but it would add code at the beginning of every function to check. Then you would have the problem of what to do when you ran out of stack space. Halt and catch fire?

    I have never looked but I assume that the dynamic memory allocation code (malloc() and friends) checks to see if it runs into the reserved stack space. That works great if the stack honors that limit.

    I am not about to examine all of your code but I did look at some and I must say that I hate the timer ISR. First up there is zero need to set the interval and start the timer again. It is still running.

    Then there is all that fiddling around with various tick counters and time intervals. Just increment the 1ms tick counter and let the foreground routines that care about such things figure it out. All you are doing here is wasting a lot of clock cycles.  Better yet, have your main loop call for a low power mode and let this ISR wake it up every tick.

    But with 10K of RAM you should have more than enough stack space. Another problem to watch out for is a wild pointer. You should be able to set watchpoints. Which cause a breakpoint when that location is modified.

  • Thanks a lot again for your hints. First things i will improve the Timer ISR and will take all of your suggestions as well.

    The breakpoint on write is a good option which i am going to try now.

    Thanks, have a great day.

  • Hi Surya,

    Does this issue have been resolved? Or still need support?

    Thanks!

    Best Regards

    Johnson

  • Hi Johnson,

    I hope yes at the moment. I made my ISRs smaller and have only the required processing inside and until now i dont see any troubles.

    I will surely get back incase i see the same strange behaviour with even more details for investigation. 

    Thanks

    Surya 

**Attention** This is a public forum