• State Resolved
  • Locked Locked
  • Replies 19 replies
  • Subscribers 53 subscribers
  • Views 3162 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Two Variables in same register although should have enough memory

Matthias Lasch
Intellectual 320 points
Other Parts Discussed in Thread: MSP430G2553

I have a little big problem. Hope you can get me in the right direction. I am developing a firmware for MSP430G2553. My IDE ist CCS 5.2; Compiler Selection is TIv4.1.5; Output format ELF (Coff gives errors, that program will not fit into mem). Nothing selected for optimization levels.

My code is as follows:

uint8_t len;

uint16_t timestamp;

uint16_t now;

LED_YELLOW_ON();

// get datalen

len = uart_rxGetByte();

// get data

timestamp = timer_getMS();

now = timer_getMS();

while(len && ((now - timestamp) < 5000)) // while further bytes outstanding or 1000ms gap

{

if(uart_rxCount())

{

buf[pos++] = uart_rxGetByte();

len--;

timestamp = timer_getMS();

}

now = timer_getMS();

}

if((now - timestamp) >= 1000)

{

continue; // if timeout ... return to while loop

}

 

What I can see is that variables len and timestamp are both located in Register R9.

 

 

Of course my program fails. Until I added this part all worked fine. So I thought I would have a stack overflow. Reduced some buffers and freed 50 Bytes of memory. Map file says, I still have space:

  name                 origin             length         used         unused      attr    fill

  RAM                   00000200   00000200  0000017c  00000084  RWIX

 

Can you halp me get the point please!?!?!?!

 

 

  • 0
    TI__Guru*** 130875 points

    Hi Matthias,

    Would you be willing to try the latest version? I wonder if you are hitting a known bug we fixed.     That would be the best thing to do.   I would do a full fresh installlation of v5.4 with antivirus disabled.

    Could you send the map file?   Double check for a bloated bss section created.   This was one bug that got fixed.

    Best Regards,
    LIsa 

  • 0 in reply to Lisa TI
    Intellectual 320 points

    Dear Lisa,

    thank you for quick support. I have downloaded and installed CCS 5.4. Done fresh installation. Unfortunately the problem is still present.

     

    Here is my map file:

    3173.Dongle_KenwoodNX.zip

     

    BSS section is 284 Bytes, but I am aware of this. I use two large buffers.  As for Me it seems, there should be enough space between variables (until 0x32C) ans stack(to 0x3B0). Why do my variables spin around?

     

  • 0 in reply to Matthias Lasch
    TI__Guru*** 130875 points

    Hi Matthias,

    thanks, we will have a look to see if anything stands out.   So what exact issue do you see?  Are you still getting code too large?   Or is it the register issue you mentioned?

    Can you provide any further details?

    Best Regards,
    Lisa 

  • 0
    Guru 92251 points

    Matthias Lasch said:
    What I can see is that variables len and timestamp are both located in Register R9.

    It looks like you may have found a bug in the MSP430 v4.1.5 compiler. Can you post your complete CCS project?

    (I did create a test program with the code fragment shown but couldn't re-create the problem)

    Matthias Lasch said:
    Nothing selected for optimization levels.
    The default is optimization level zero, which can place variables in registers. If you set CCS Project Properties -> Build -> MSP Compiler -> Optimization -> Optimization Level to "Off", which will disable all optimization, does that make the problem go away?

  • 0 in reply to Chester Gillon
    TI__Guru**** 173310 points

    Matthias,

    As mentioned by Chester there could be a bug in the MSP430 compiler, however we would need a test case to reproduce the problem before we can analyze it further. If you can zip up and attach your CCS project we can take a look.  Also as suggested by Chester a short-term workaround could be to turn off optimization completely in your project settings.

  • 0 in reply to AartiG
    Intellectual 320 points

    Dear TI and Community,

    Sorry I was away for some days. I admit that I was not amused by the thought of publishing my project.However I brought myself to uploading my project to an FTP, which will be available for some days:

    ftp://11078181.server04.storage.hosteurope.de/

    User:  Gast0103
    PW:  Frl3NgFr

     

    Pay special attention to the define "BUFSIZE" in main.h. Even shrinking it down had NO (!!!) effect. When activating the timeout in main.c lines 170ff makes me trouble. Hope you can help me find the damn mistake.

     

    Best Regards,
    Matthias

  • 0 in reply to Matthias Lasch
    TI__Guru* 84225 points

    If you would feel more comfortable sending this material only to TI personnel, you could send me a private message through the link on my profile page.

    Note: I tried to log into the FTP server with the credentials you show, but it failed authentication.

    [edit: I've opened SDSCM00047909 to track this issue, whatever it turns out to be.]

  • 0 in reply to Archaeologist
    Intellectual 320 points

    Fat sorry!!!

    username is: ftp11078181-Gast0103

     

  • 0 in reply to Matthias Lasch
    TI__Guru* 84225 points

    The credentials were accepted, but I cannot get a directory listing.  Here is the error I get:

    ftp> ls
    500 command not understood

    421 Service not available, remote server timed out. Connection closed

  • 0 in reply to Archaeologist
    Intellectual 320 points

    Hi archaeologist,

    I do not see an error accessing the FTP with the given credentials. Tried out any FTP clients (Filezilla, IE10, Win-Explorer). Which OS and client are you using? Sure that your firewall does not block? Tried out active and passive mode?

    Anyone else that cannot access the zip file?

     

    Best Regards,
    Matthias

  • 0 in reply to Matthias Lasch
    TI__Guru* 84225 points

    Okay, I used a different client and fetched the ZIP file.  Looking at it now.

  • 0 in reply to Archaeologist
    TI__Guru* 84225 points

    I am not able to immediately see what the problem is.  I see that you've sent a project containing a successfully-built COFF executable file, so the project does not demonstrate the error you mentioned in your first post ("Coff gives errors, that program will not fit into mem").  I see that the main.c has the timestamp variable commented out, so it does not demonstrate that len and timestamp occupy the same register.  Could you please state exactly how to compile the program such that it demonstrates the problem you want fixed, and also state exactly how you know it is a problem?

  • 0
    Guru 92251 points

    Matthias Lasch said:
    What I can see is that variables len and timestamp are both located in Register R9.

    It wasn't clear from the original code fragment, but from looking at the main function in the complete project shows two variables named len at different scopes in the main function:

    void main(void)
     {


     // read configuration
     {
      uint16_t lenConfig;
      uint16_t lenRead;

      if(true == flash_readConfig((uint8_t*)&buf, &lenConfig, &lenRead, sizeof(buf), 0))
      {
       for(pos=0; pos<lenRead; )
       {
        config_t param;
        uint8_t len;
        uint8_t* value;

        param = (config_t) buf[pos];
        len = buf[pos+1];
        ...
       }
      }
     }

     while(true)
     {
      pos = 0;

      if(uart_rxCount())
      {
       uint8_t len;
       uint16_t timestamp;

       LED_YELLOW_ON();

       // get datalen
       len = uart_rxGetByte();

       // get data
       timestamp = timer_getMS();
       ...
      }
     }
    }

    Looking at the disassembly shows that:
    - len in the first block is allocated to R9
    - len in the second block is allocated to R10
    - timestamp in the second block is allocated to R9

    Therefore, from looking at the disassembly the compiler has correctly allocated len and timestamp to different registers.

    The CCS debugger Variables tab is only reporting one len local variable in the main function, allocated to R9 (which is the len variable from the first block). The issue is that the CCS debugger doesn't appear to expect two different local variables with the same name at different scopes within the same function and ends up only displaying the len variable allocated to R9 (from the first block) which happens to have the same register as the timestamp variable in the second block, leading to the appearance that the compiler has allocated two variables in the same block to the same register.

  • 0
    TI__Guru* 84225 points

    Okay, so it seems reasonably likely that that is a flaw in CCS.  Thus, we can't necessarily use that display to prove a symptom has occurred.

    In your original post, you say:

    Matthias Lasch said:
    Of course my program fails.

    Okay, so there's still a bug here somewhere.  How do you know your program has failed?

  • 0
    Guru 92251 points

    Matthias Lasch said:
    Until I added this part all worked fine. So I thought I would have a stack overflow.

    Have you tried calculating the worse case stack usage using Finding out static stack usage? Running the call_graph script on the attached project changed to add back the timeout code in main, reported:
    - Maximum stack usage from main as 68 bytes
    - Maximum stack usage from an interrupt handler of 6 bytes (for USCI0RX_ISR and USCI0TX_ISR)

    i.e. maximum stack usage of 74 bytes which is less than the 80 bytes allocated for the stack. i.e. don't think there is a stack overflow problem in the attached project. However, there is only 6 bytes spare of stack usage so a future change may required an increase in the allocated stack size.

  • 0 in reply to Chester Gillon
    Intellectual 320 points

    OK there is much truth in what you posted here. I see myself on the way to solution. Yes there were identical variable names (Why does CCS permit such???). After I named them clearly, I see no overlap.

    I also checked the stack size and can see the same results as mentioned, which means there will be no overflow yet.

    My program now does not fail anymore. However, I get some strange things shown. Check the screenshot:

     

    I always get into the routine on line 184, even if there is a timeout, which is exactly calculated. Assambly ststes that here would be the comparison:

     

    ???

  • 0 in reply to Matthias Lasch
    TI__Guru* 84225 points

    Matthias Lasch said:
    Yes there were identical variable names (Why does CCS permit such???).

    Because the C standard requires CCS to support it.  The two variables named "len" were in disjoint scopes, so they are OK as far as the language is concerned.

  • 0 in reply to Matthias Lasch
    Guru 92251 points

    Matthias Lasch said:
    I always get into the routine on line 184, even if there is a timeout, which is exactly calculated. Assambly ststes that here would be the comparison:

    I had a similar same issue with my version, based on your attached project with:
    - flash_init modified to always return true (as was using a Launchpad with no SPI flash connected)
    - The timeout code inserted.

    The main code I was using:

    And the assembler generated by MSP430 compiler v4.1.6:

    With a CCS break point set on line 183 the break point was "hit" even when there was no timeout, which wasn't the expected behaviour. Whereas a break point set on line 194 was only hit when there wasn't a timeout, which is the expected behaviour.

    In the source code line 181 contains a test on the timeout, and line 183 contains a continue which should only be executed when timeout occurs. However, looking at the assembler shows the test and continue (jump) have both been indicated as on source line 183 in the debugging information. Therefore, it appears the code operates as expected, but the debugging is confusing since the code generated for a test on source line 181 has been indicated as on line 183 in the debugging information.

    Could the debugging information produced by the compiler be improved to avoid this?

  • 0 in reply to Archaeologist
    Intellectual 320 points

    OK, my expression was a little bit confusing. What I mean:

    CCS normally indicates me, when variables are not valid within the current scope. Now when there are two variables "len" (and of course only one of it can be valid here), CCS gives me the content of the variable, which is no more valid in this scope. This was confusing me.

    I do not know, if the issue mentioned by Chester Gillon makes out a new problem, but the main question of this thread is answered. Thank you very much guys.