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.

MSP430 ocassional lockup when hex file loaded with CCS 4.0 via MSP-FETU430IF, system works when loaded via Elprotronic FET-Pro430

Other Parts Discussed in Thread: MSP430F2410

I have an application running on a MSP430F2410 that works fine, and has had no issues for a year.  Optimizations are all turned off.   I added a very minor code change, and it still works "most of the time", but ocassionally when processing an interrupt, it now locks up (with or without the debugger being attached).   If I have a debugger attached (running CCS 4.2.5.00005, via MSP-FETU430IF) it acts like it hit a break point in an area of the code that has no break point.   When the same hex file is loaded via the Elprotronic FET-Pro430, the problem does not occure.  

If I load it via CCS with Tool Settings/Basic Options/Debugging Model "suppress all symbolic debugging".   It also "seems to work" without the lockup.

Can anyone explain this issue?   If I build with "symbolic debugging" enabled, I assume some "debugger extras" are in the code or at least some memory (possibly between the end of the used area of .bss and the start of the stack) is reserved for the debugger.   Do they leave in hooks to capture the ISR's for the debugger use?

Looking for clarification, I dont want to assume the "work arround" (turn debugging off, load via Elprotronic FET-Pro430) was a magic fix and have issue later on, under use or when the lext minor code change is needed...

What is different in the MSP after loading the hex files via the two tools? 

If I build without "symbolic debugging" enabled, what (besides the symbol table info) is different on the MSP?

 

  • As an additional test, I verified the stack usage under load:

    Before the program was run (at breakpoint in main), the map shows the expected uninitialized random data in the stack.   I then cleared the unused stack memory using "Fill Memory", and the system was run in the debugger through varioues tests generating a lot of interrupts, and then paused.    The stack utilization was verified to be in the acceptable range and not come close to overflowing the stack.

    So:

    What is different in the MSP 430 after loading the same hex files via the CCS 4.2.5.00005 and the Elprotronic FET-Pro430 using the same MSP-FETU430IF?

     

     

     

  • David Collins said:
    What is different in the MSP 430 after loading the same hex files via the CCS 4.2.5.00005 and the Elprotronic FET-Pro430 using the same MSP-FETU430IF?

    In theory, nothing. If the same linker output is used in both cases, the MSP should contain the same content after upload.

    However, there are some possible differences.

    First, you may have chosen different erase modes for the two uploads. Since in any case the required area is erased before flashing, this shouldn't make no difference, but under certain circumstances, it might. Mostly if the software assumes things that are not true if the flash memory wasn't completely erased before flashing.

    Also, the algorithm that is used to upload the software to the MSP might be different too. MSPGCC, for example, uploads a small piece of code to ram, along with tome data, and executes it. The code then performs the necessary erase oepration and writes its attached data. Then the next data piece is written to ram through JTAG etc.
    CCS and Flash-Pro may use a slightly different algorithm. Maybe this makes a difference for this specific MSP.

    Also, when using the FET430UIF, both may use a different setup for the FET. Different operating voltage while flashing, maybe one is using SBW while the other uses 4-wire JTAG. Even the way how the MSP is reset before/after flashing might be different (power cycle, RST signal, software reset).

    As I said, normally there shouldn't be a difference. Normally, things should work either way. But beyond normally, there are quite a few things that might be different and might make a difference. However, things like this can usually only be sorted out with the real hardware in hands, so it's mostly up to you to figure out what's going on.

**Attention** This is a public forum