• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 80 subscribers
  • Views 2170 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.

MSP430f5438A Debug Custom BSL

Matt Gigli
Prodigy 250 points
Other Parts Discussed in Thread: MSP430F5438, Z-STACK

I am trying to follow the instructions found in SLAA450 Section 5.1 about developing and testing a custom BSL for the 5438A, but it says to use the "FLASH_AREA" linker file found in the CONFIG directory, but I don't seem to have the FLASH_AREA linker file anywhere in the .zip that I downloaded from http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/CustomBSL/latest/index_FDS.html. I tried using the MSP430F5438.xcl file from my Z-Stack project, but I get some very peculiar behavior when I try to debug through the code; for example, I can breakpoint to the beginning of PI_receivePacket(), but after setting the RX_StatusFlags, it jumps from that statement down all the way down into one of the else if statements (from clicking the "Next Statement" in the degbugger). Does anyone know where to get the FLASH_AREA linker file that the app note talks about using to debug the BSL code?

Thanks,

Matt

  • 0
    TI__Guru 56650 points

    Matt,

    it was available in the previous version of the SLAA450 associated files.

    Attached you can have the copy of the FLASH_AREA linker file for MSP40F543xA devices:

    http://e2e.ti.com/cfs-file.ashx/__key/CommunityServer-Discussions-Components-Files/166/4034.lnk430F5438_5F00_FLASH_5F00_AREA.xcl

    Hope this helps and sorry for the confussion, i will forward this information to the MSP430 BSL team.

  • 0 in reply to Leo Hendrawan
    Prodigy 250 points

    Thank you very much! Unfortunately, I'm still having the same problem.. I'll try to be more specific. I am using the USCIA peripheral instead of the Timer A peripheral, and I'm debugging within the PI_receivePacket() function. The first line is:

    char RX_StatusFlags = RX_PACKET_ONGOING;

    I set a breakpoint on this statement:

    and step to the Next Statement, and it jumps all the way down to:

    and completely skips everything in between. Why does this happen????

  • 0 in reply to Matt Gigli
    TI__Guru 56650 points

    Matt,

    you might want to check the compiler optimization on the IAR. Go to "Project" -> "Options" as shown below:

    Debugging with compiler optimizations set to "High" might give you headache :), so set it to "Low" to make the debugging process more understandable.

    -Leo-

  • 0 in reply to Leo Hendrawan
    Prodigy 250 points

    Ah, thank you so much!

  • 0 in reply to Matt Gigli
    Guru 227245 points

    Just to add an explanation why optimization can cause this:

    Thsi statement might be common to more than one part of the code. Or won't change the program flow if done on a different location. maybe it will allow the usage of register variables or re-use of comparison results if done somewhere else. The compiler will detect this and actually move it out of the IF clause. The debugger, however, reaches the binary code location, and all it knows is that the source code that caused this binary code, was on this line. So it shows the break there. And this does not necessarily mean that the next instruciton executed is the next isntruction in the source code.
    It makes debugging a really confusing process.

    So compiler optimization, which han shrink code size by up to 50% while at the same time increasing execution speed, should not be used for debugging the program (if the available and required flash size allows it).
    However, switchng it on after the program works means that the program needs to be tested again, since the timing will have changed (and reveal previously undetected code flaws). Also, in some rare cases, compiler optimization will break working code due to unexpected side-effects. Mostly related to undetected compiler bugs, but sometimes due to sloppy code that coincidentally worked without optimization (and probably would have failed on the next compiler version anyway, even without optimization)

**Attention** This is a public forum