• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 54 subscribers
  • Views 2852 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Generation of warning #10420-D by MSP430 linker v4.3.3

Chester Gillon
Guru 92251 points

Other Parts Discussed in Thread: MSP430FR5969, MSP-EXP430FR5969

The attached example project 0310.FRAM_grace_blink_the_LED.zip  generated by Grace 3.0.1.59 for a MSP430FR5969 generates the following warning during linking:

warning #10420-D: For FRAM devices, at start up, the GPO power-on default high-impedance mode needs to be disabled to activate previously configured port settings. This can be done by clearing the LOCKLPM5 bit in PM5CTL0 register.

However, from single stepping the code the LOCKLPM5 bit is cleared in the PM5CTL0 register inside the PMM_unlockLPM5 function:

Therefore, is it correct for warning #10420-D to be reported?

[The help for warning #10420-D says it is reported if the PM5CTL0.LOCKPM5 bit clearing code instruction cannot be detected in the project]

  • 0
    TI__Guru**** 253390 points

    The wiki article for this diagnostic says to use the C code sequence ...

    PM5CTL0 &= ~LOCKLPM5;

    This generates the assembly instruction ...

    BIC.W     #1,&PM5CTL0+0

    That is close, but not identical to the BIC instruction your project uses.  So, that is why the linker is complaining.  That doesn't mean the linker is correct.  I have contacted an expert on this, but I don't expect to hear back until Wednesday or so.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    TI__Expert 5795 points

    Chester,

    The rule checks for an assignment to PM5CTL0 or PM5CTL0_L but then does final determination at link time so library code can participate.

    However, it looks like Grace is using a different method that the parser is not detecting.  I'll work with the Grace team to determine best approach to resolve this whether pmm.c or parser.

    In the mean time, it does appear that the advice is invalid and can be ignored.  As a short term work around, you can disable the check in "Project Properties" => "MSP430 Compiler" -> "Advice options" 

    Change the check boxes to only have rule 1.2 checked.  You may have to select NONE before only selecting 1.2 (my first try at unchecking 1.1 still had "all" as the choice in console).

    Regards

    Greg

  • 0 in reply to GregM
    Intellectual 775 points

    Its not just in grace - the OOB example that comes with the MSP-EXP430FR5969 LaunchPad just uses Driverlib and uses PMM_unlockLPM5(); in its GPIO init routine.

    You still get the #10420-D warning when it seems you shouldn't - the rule perhaps should be expanded to be a bit more flexible...

    Also, I would suggest that ignoring the warning for now is far better than disabling the check which may result in the user just forgetting about the issue in future projects.

    Slightly irritating though the warning is (to those of us who insist on clean compiles), it serves as a reminder that there is an issue there (however small) that needs to be resolved :)