Re: [msp430-elf] Interrupt vector corrupted?

[Orlando Arias <orlandoarias at gmail dot com>]

Greetings

I finally have some time to look into this issue [and help with the
testing if possible]. As requested, I have filed a bug report [1]. Also,
I have tested your patches and whilst objdump does not disassemble past
the bounds of the section anymore, its output is somewhat funny.

Disassembly of section __interrupt_vector_47:

0000ffdc <__interrupt_vector_47>:
    ffdc:       d8 49           Address 0x000000000000ffde is out of bounds.
Address 0x000000000000ffde is out of bounds.
mov.b                   ;<memory read failed>, <memory read failed>

Disassembly of section __interrupt_vector_54:

0000ffea <__interrupt_vector_54>:
    ffea:       6e 49           interrupt service routine at 0x496e

Disassembly of section .lowtext:


For all practical purposes, this is OK, since I can infer from context
what is going on, but it would be nice to have all interrupts rendered
like __interrupt_vector_54.

As for the reboots, you are most likely correct. It may be a hardware
issue although as far as I have seen, there is no errata for this
particular model. I will keep looking into it.

Thank you for your time.

Cheers,
Orlando.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=20150

On 04/19/2016 06:54 AM, Nick Clifton wrote:
> 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
>

Attachment: signature.asc
Description: OpenPGP digital signature