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.

msp430fr5739: Jump to weird address

Other Parts Discussed in Thread: MSP430FR5739

Hello all,


I am testing a msp430fr5739 with an Anaren Boostpack and it seems that everytime I make a successful transmission, the program counter jumps to an address 0x33ffe after returning from an interrupt handler. What could be going on here?

Regards,

Shailesh

  • An awfully lot of awful things could be going on there. This includes, of course, that the SP is pointing to the wrong return address 0x33ffe.
  • 0x3ffe is what you typically get for invalid memory accesses. This sounds as if the stack pointer was set to an invalid address.
  • Okay, I have dug a bit further and it seems that functions declared in external files are having some trouble returning to the main function. Calls from one external file to another are working without any issues. Is there something wrong with my function declarations? My function calls are made by CALLA. At the beginning of the functions though, I don't see any PUSH instructions. Neithere are there any POP instructions before the RETA instruction. According to the manual, this should not be the case.
  • Ok, some more actual information:
    I am making a call in main from the location 0xca60 to a function called send byte. Send byte makes a call to function 1 which in turn makes a call to function 2. The control returns from function 2 to function 1 to send byte without any issues. Now though, send byte returns to a location 0xc9fe (about 100 odd bytes before where it should be ending up). Has anyone ever had such an issue?

    I am absolutely clueless as to what might be causing this.
  • I have found the problem and I could tear my hair out in frustration and joy but before that let me vent out some anger at the folks at TI.

    The problem was that I had allocated an array of bytes, 60 bytes long. Now, my code was accessing the 61st byte by mistake and normally a compiler would raise a flag about it. Not here, the compiler just happily went on and overwrote an address in the stack throwing everything out of sync. It costed me a good half a day but this has been a nice learning curve. Found out about a lot of features of CCS6 that I would not have found out about otherwise. Suddenly everything works the way it is supposed to. What a relief :P
  • I stand corrected. C does not employ such checks the way Python does. So my rant at TI is uncalled for. My bad.

**Attention** This is a public forum