[msp430-elf] Interrupt vector corrupted?

[Nick Clifton]

Hi Orlando,

  First of all, it is best to report problems like this using the binutils
  bugzilla system.  That way we can keep track of the issue and refer back
  to it later if needed.

> The reason I am asking is because I am seeing extra data being added to
> the section and I am experiencing the microcontroller crash 

  The attached patch will stop objdump from displaying extra bytes in the 
  disassembly of the interrupt vector.  But, as DJ indicated, this is not
  the source of the problem you are experiencing.  Objdump was just displaying
  a couple of random bytes because of some poor coding which did not take
  into account the possibility of an attempt to read beyond the end of a
  section.  In practice however interrupt vector 47 really is only 2 bytes
  long, and there are no extraneous values being installed into the vector
  table.

  You can check this by examining the executable using readelf.  For example:

  % readelf --wide -S a.out

  [ 1] __interrupt_vector_47 PROGBITS        0000ffdc 0003d0 000002 00  AX  0   0  1
                                                              ^^^^^
                                                             the size
  % readelf -x1 a.out

  Hex dump of section '__interrupt_vector_47':
    0x0000ffdc c445                                .E



> As an addendum, I should add that the microcontroller resets when
> attempting to execute the ISR. The behaviour can not be replicated with
> USCI_A0_VECTOR [of course, enabling proper interrupts in either case].

  So does this mean that if you use USCI_A0_VECTOR your program works,
  but if you use USCI_A1_VECTOR it does not ?  I am not an MSP430 MCU
  expert, but to me this indicates that there is some kind of hardware
  based problem with using the A1 vector.

Cheers
  Nick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: msp430-dis.c.patch
Type: text/x-patch
Size: 24796 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20160419/d1d5f166/attachment.bin>