This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |