> On Oct 25, 8:27 am, Tim Wescott <t...@seemywebsite.com> wrote:
>> On Tue, 25 Oct 2011 10:21:23 -0500, Tim Wescott wrote:
>> > On Tue, 25 Oct 2011 08:03:23 +0100, MK wrote:
>>
>> >> On 25/10/2011 07:16, Tim wrote:
>> >>> On Mon, 24 Oct 2011 16:23:58 -0400, Rich Webb wrote:
>>
>> >>>> On Mon, 24 Oct 2011 13:27:40 -0500, Tim
>> >>>> Wescott<t...@seemywebsite.com> wrote:
>>
>> >>>>> Just starting to use the TMS470R1B1, which is a high-temp,
>> >>>>> high-rel processor with the ARM M3 core.
>>
>> >>>>> At the customer's insistence I'm using the IAR IDE, and
>> >>>>> interrupts are all f***ed up. Even the IAR demos don't work, and
>> >>>>> the register definitions in the ever-so-easy-to-find files don't
>> >>>>> match the documentation or, apparently, reality.
>>
>> >>>>> I'm trying to figure out how much of this is me, how much is IAR,
>> >>>>> how much is TI, and how much is ARM.
>>
>> >>>>> So if anyone has happened to use that particular set of tools
>> >>>>> with that processor (or if the symptoms sound right for _any_ IAR
>> >>>>> IDE with a Cortex M3), I'd like to hear how you solved the
>> >>>>> problems.
>>
>> >>>> That doesn't sound good (I know: Hello, Mr Obvious!). Check
>> >>>> whether the vector table offset register is getting set to the
>> >>>> expected value.
>>
>> >>> At the moment I'm pretending that interrupts were never invented,
>> >>> but I'll be doing something like that in my investigations.
>>
>> >>> I just found out that the SPI register definitions are completely
>> >>> wrong -- it's like they took the definitions for a completely
>> >>> different processor and put them into the header file with my
>> >>> processor's name.
>>
>> >>> Granted, it's an obscure high-temperature part I'm using (I can't
>> >>> remember the number off hand, SM470R1B1 or some such), but I pulled
>> >>> the data sheet for the TMS470R1B1 to double-check, and they match).
>> >>> I suspect that some serious bugs have managed to check themselves
>> >>> into the code tree without getting found.
>>
>> >>> I suppose I should email them, give 'em a chance to do something
>> >>> about it. This is _frustrating_. When the customer said "we'll
>> >>> get the IAR system so we'll all be on the same IDE" I kinda rolled
>> >>> my eyes, because as far as I'm concerned an IDE is just training
>> >>> wheels that keep you up but wobbly, for as long as the project goes
>> >>> in the direction that the IDE vendor anticipated. But I figured
>> >>> it'd be about their speed, and after all we'd at least _get the
>> >>> damn thing working_.
>>
>> >> Hello Tim,
>> >> I couldn't find many references - a search on TI website comes up
>> >> blank - but it seems to be an ARM7 not a Cortex M3 - if your tools
>> >> are set up for an M3 there is no way it will work. ARM7 interrupts
>> >> are horrible (for embedded stuff) and completely different.
>> >> Michael Kellett
>>
>> > Somehow I ended up with an architectural manual for the "TMS470M"
>> > that _does_ list an M3 core. I'm pretty sure that the TI web site
>> > pointed to that document for me, but I may have provided my own
>> > screw-ups. Finding the _right_ architectural manual for the chip
>> > will probably go a long way toward alleviating confusion.
>>
>> It _was_ TI!!! The data sheet lists the ARM7TDMI core, but the
>> processor user's guide that they refer to lists the Cortex M3.
>>
>> Grrr.
>>
>> Somehow I suspect that the TMS470M, whatever that is, is a TMS470R with
>> a Cortex M3 slipped in there. Which doesn't help me very much at all,
>> but certainly saves me from the stupidest of mistakes.
>
> Yes, i believe TMS470 is ARM7. That's why TI brought LMI for the M3
> design in the first place.
I like the ex-Luminary parts. Of course, I haven't tried using their
power-down modes, which are, I am told, fraught with errors in the
silicon.
I have a customer who has used them, and ended up with an 8-pin AVR or PIC
or similar just to bring the main chip out of sleep mode. For some
reason, they don't use the ex-Luminary parts any more.
--
www.wescottdesign.com
Reply by linnix●October 25, 20112011-10-25
On Oct 25, 8:27=A0am, Tim Wescott <t...@seemywebsite.com> wrote:
> On Tue, 25 Oct 2011 10:21:23 -0500, Tim Wescott wrote:
> > On Tue, 25 Oct 2011 08:03:23 +0100, MK wrote:
>
> >> On 25/10/2011 07:16, Tim wrote:
> >>> On Mon, 24 Oct 2011 16:23:58 -0400, Rich Webb wrote:
>
> >>>> On Mon, 24 Oct 2011 13:27:40 -0500, Tim Wescott<t...@seemywebsite.co=
m>
> >>>> wrote:
>
> >>>>> Just starting to use the TMS470R1B1, which is a high-temp, high-rel
> >>>>> processor with the ARM M3 core.
>
> >>>>> At the customer's insistence I'm using the IAR IDE, and interrupts
> >>>>> are all f***ed up. =A0Even the IAR demos don't work, and the regist=
er
> >>>>> definitions in the ever-so-easy-to-find files don't match the
> >>>>> documentation or, apparently, reality.
>
> >>>>> I'm trying to figure out how much of this is me, how much is IAR,
> >>>>> how much is TI, and how much is ARM.
>
> >>>>> So if anyone has happened to use that particular set of tools with
> >>>>> that processor (or if the symptoms sound right for _any_ IAR IDE
> >>>>> with a Cortex M3), I'd like to hear how you solved the problems.
>
> >>>> That doesn't sound good (I know: Hello, Mr Obvious!). Check whether
> >>>> the vector table offset register is getting set to the expected
> >>>> value.
>
> >>> At the moment I'm pretending that interrupts were never invented, but
> >>> I'll be doing something like that in my investigations.
>
> >>> I just found out that the SPI register definitions are completely
> >>> wrong -- it's like they took the definitions for a completely
> >>> different processor and put them into the header file with my
> >>> processor's name.
>
> >>> Granted, it's an obscure high-temperature part I'm using (I can't
> >>> remember the number off hand, SM470R1B1 or some such), but I pulled
> >>> the data sheet for the TMS470R1B1 to double-check, and they match). =
=A0I
> >>> suspect that some serious bugs have managed to check themselves into
> >>> the code tree without getting found.
>
> >>> I suppose I should email them, give 'em a chance to do something abou=
t
> >>> it. =A0This is _frustrating_. =A0When the customer said "we'll get th=
e IAR
> >>> system so we'll all be on the same IDE" I kinda rolled my eyes,
> >>> because as far as I'm concerned an IDE is just training wheels that
> >>> keep you up but wobbly, for as long as the project goes in the
> >>> direction that the IDE vendor anticipated. =A0But I figured it'd be
> >>> about their speed, and after all we'd at least _get the damn thing
> >>> working_.
>
> >> Hello Tim,
> >> I couldn't find many references - a search on TI website comes up blan=
k
> >> - but it seems to be an ARM7 not a Cortex M3 - if your tools are set u=
p
> >> for an M3 there is no way it will work. ARM7 interrupts are horrible
> >> (for embedded stuff) and completely different.
> >> =A0 Michael Kellett
>
> > Somehow I ended up with an architectural manual for the "TMS470M" that
> > _does_ list an M3 core. =A0I'm pretty sure that the TI web site pointed=
to
> > that document for me, but I may have provided my own screw-ups. =A0Find=
ing
> > the _right_ architectural manual for the chip will probably go a long
> > way toward alleviating confusion.
>
> It _was_ TI!!! =A0The data sheet lists the ARM7TDMI core, but the process=
or
> user's guide that they refer to lists the Cortex M3.
>
> Grrr.
>
> Somehow I suspect that the TMS470M, whatever that is, is a TMS470R with a
> Cortex M3 slipped in there. =A0Which doesn't help me very much at all, bu=
t
> certainly saves me from the stupidest of mistakes.
Yes, i believe TMS470 is ARM7. That's why TI brought LMI for the M3
design in the first place.
Reply by Tim Wescott●October 25, 20112011-10-25
On Tue, 25 Oct 2011 10:21:23 -0500, Tim Wescott wrote:
> On Tue, 25 Oct 2011 08:03:23 +0100, MK wrote:
>
>> On 25/10/2011 07:16, Tim wrote:
>>> On Mon, 24 Oct 2011 16:23:58 -0400, Rich Webb wrote:
>>>
>>>> On Mon, 24 Oct 2011 13:27:40 -0500, Tim Wescott<tim@seemywebsite.com>
>>>> wrote:
>>>>
>>>>> Just starting to use the TMS470R1B1, which is a high-temp, high-rel
>>>>> processor with the ARM M3 core.
>>>>>
>>>>> At the customer's insistence I'm using the IAR IDE, and interrupts
>>>>> are all f***ed up. Even the IAR demos don't work, and the register
>>>>> definitions in the ever-so-easy-to-find files don't match the
>>>>> documentation or, apparently, reality.
>>>>>
>>>>> I'm trying to figure out how much of this is me, how much is IAR,
>>>>> how much is TI, and how much is ARM.
>>>>>
>>>>> So if anyone has happened to use that particular set of tools with
>>>>> that processor (or if the symptoms sound right for _any_ IAR IDE
>>>>> with a Cortex M3), I'd like to hear how you solved the problems.
>>>>
>>>> That doesn't sound good (I know: Hello, Mr Obvious!). Check whether
>>>> the vector table offset register is getting set to the expected
>>>> value.
>>>
>>> At the moment I'm pretending that interrupts were never invented, but
>>> I'll be doing something like that in my investigations.
>>>
>>> I just found out that the SPI register definitions are completely
>>> wrong -- it's like they took the definitions for a completely
>>> different processor and put them into the header file with my
>>> processor's name.
>>>
>>> Granted, it's an obscure high-temperature part I'm using (I can't
>>> remember the number off hand, SM470R1B1 or some such), but I pulled
>>> the data sheet for the TMS470R1B1 to double-check, and they match). I
>>> suspect that some serious bugs have managed to check themselves into
>>> the code tree without getting found.
>>>
>>> I suppose I should email them, give 'em a chance to do something about
>>> it. This is _frustrating_. When the customer said "we'll get the IAR
>>> system so we'll all be on the same IDE" I kinda rolled my eyes,
>>> because as far as I'm concerned an IDE is just training wheels that
>>> keep you up but wobbly, for as long as the project goes in the
>>> direction that the IDE vendor anticipated. But I figured it'd be
>>> about their speed, and after all we'd at least _get the damn thing
>>> working_.
>>>
>> Hello Tim,
>> I couldn't find many references - a search on TI website comes up blank
>> - but it seems to be an ARM7 not a Cortex M3 - if your tools are set up
>> for an M3 there is no way it will work. ARM7 interrupts are horrible
>> (for embedded stuff) and completely different.
>> Michael Kellett
>
> Somehow I ended up with an architectural manual for the "TMS470M" that
> _does_ list an M3 core. I'm pretty sure that the TI web site pointed to
> that document for me, but I may have provided my own screw-ups. Finding
> the _right_ architectural manual for the chip will probably go a long
> way toward alleviating confusion.
It _was_ TI!!! The data sheet lists the ARM7TDMI core, but the processor
user's guide that they refer to lists the Cortex M3.
Grrr.
Somehow I suspect that the TMS470M, whatever that is, is a TMS470R with a
Cortex M3 slipped in there. Which doesn't help me very much at all, but
certainly saves me from the stupidest of mistakes.
--
www.wescottdesign.com
Reply by Tim Wescott●October 25, 20112011-10-25
On Tue, 25 Oct 2011 08:03:23 +0100, MK wrote:
> On 25/10/2011 07:16, Tim wrote:
>> On Mon, 24 Oct 2011 16:23:58 -0400, Rich Webb wrote:
>>
>>> On Mon, 24 Oct 2011 13:27:40 -0500, Tim Wescott<tim@seemywebsite.com>
>>> wrote:
>>>
>>>> Just starting to use the TMS470R1B1, which is a high-temp, high-rel
>>>> processor with the ARM M3 core.
>>>>
>>>> At the customer's insistence I'm using the IAR IDE, and interrupts
>>>> are all f***ed up. Even the IAR demos don't work, and the register
>>>> definitions in the ever-so-easy-to-find files don't match the
>>>> documentation or, apparently, reality.
>>>>
>>>> I'm trying to figure out how much of this is me, how much is IAR, how
>>>> much is TI, and how much is ARM.
>>>>
>>>> So if anyone has happened to use that particular set of tools with
>>>> that processor (or if the symptoms sound right for _any_ IAR IDE with
>>>> a Cortex M3), I'd like to hear how you solved the problems.
>>>
>>> That doesn't sound good (I know: Hello, Mr Obvious!). Check whether
>>> the vector table offset register is getting set to the expected value.
>>
>> At the moment I'm pretending that interrupts were never invented, but
>> I'll be doing something like that in my investigations.
>>
>> I just found out that the SPI register definitions are completely wrong
>> -- it's like they took the definitions for a completely different
>> processor and put them into the header file with my processor's name.
>>
>> Granted, it's an obscure high-temperature part I'm using (I can't
>> remember the number off hand, SM470R1B1 or some such), but I pulled the
>> data sheet for the TMS470R1B1 to double-check, and they match). I
>> suspect that some serious bugs have managed to check themselves into
>> the code tree without getting found.
>>
>> I suppose I should email them, give 'em a chance to do something about
>> it. This is _frustrating_. When the customer said "we'll get the IAR
>> system so we'll all be on the same IDE" I kinda rolled my eyes, because
>> as far as I'm concerned an IDE is just training wheels that keep you up
>> but wobbly, for as long as the project goes in the direction that the
>> IDE vendor anticipated. But I figured it'd be about their speed, and
>> after all we'd at least _get the damn thing working_.
>>
> Hello Tim,
> I couldn't find many references - a search on TI website comes up blank
> - but it seems to be an ARM7 not a Cortex M3 - if your tools are set up
> for an M3 there is no way it will work. ARM7 interrupts are horrible
> (for embedded stuff) and completely different.
> Michael Kellett
Somehow I ended up with an architectural manual for the "TMS470M" that
_does_ list an M3 core. I'm pretty sure that the TI web site pointed to
that document for me, but I may have provided my own screw-ups. Finding
the _right_ architectural manual for the chip will probably go a long way
toward alleviating confusion.
--
www.wescottdesign.com
Reply by Rich Webb●October 25, 20112011-10-25
On Tue, 25 Oct 2011 01:16:39 -0500, Tim <tim@seemywebsite.please> wrote:
>On Mon, 24 Oct 2011 16:23:58 -0400, Rich Webb wrote:
>
>> On Mon, 24 Oct 2011 13:27:40 -0500, Tim Wescott <tim@seemywebsite.com>
>> wrote:
>>
>>>Just starting to use the TMS470R1B1, which is a high-temp, high-rel
>>>processor with the ARM M3 core.
>>>
>>>At the customer's insistence I'm using the IAR IDE, and interrupts are
>>>all f***ed up. Even the IAR demos don't work, and the register
>>>definitions in the ever-so-easy-to-find files don't match the
>>>documentation or, apparently, reality.
>>>
>>>I'm trying to figure out how much of this is me, how much is IAR, how
>>>much is TI, and how much is ARM.
>>>
>>>So if anyone has happened to use that particular set of tools with that
>>>processor (or if the symptoms sound right for _any_ IAR IDE with a
>>>Cortex M3), I'd like to hear how you solved the problems.
>>
>> That doesn't sound good (I know: Hello, Mr Obvious!). Check whether the
>> vector table offset register is getting set to the expected value.
>
>At the moment I'm pretending that interrupts were never invented, but
>I'll be doing something like that in my investigations.
Even if you don't use interrupts, yet, the table gets used. The first
entry in the exception table is the value of the main stack pointer and
the second is the application entry point. Also, as Arlet mentions, the
alignment is not arbitrary. Presumably, though, they got the basic
(generic CM3) part right else you'd not even start up.
>I just found out that the SPI register definitions are completely wrong
>-- it's like they took the definitions for a completely different
>processor and put them into the header file with my processor's name.
I should be callused enough by now to not be surprised by this but it
still astounds me.
>Granted, it's an obscure high-temperature part I'm using (I can't
>remember the number off hand, SM470R1B1 or some such), but I pulled the
>data sheet for the TMS470R1B1 to double-check, and they match). I
>suspect that some serious bugs have managed to check themselves into the
>code tree without getting found.
Oh well, that's why embedded developers get the big bucks. ;-)
--
Rich Webb Norfolk, VA
Reply by John Devereux●October 25, 20112011-10-25
Tim <tim@seemywebsite.please> writes:
> On Mon, 24 Oct 2011 16:23:58 -0400, Rich Webb wrote:
>
>> On Mon, 24 Oct 2011 13:27:40 -0500, Tim Wescott <tim@seemywebsite.com>
>> wrote:
>>
>>>Just starting to use the TMS470R1B1, which is a high-temp, high-rel
>>>processor with the ARM M3 core.
>>>
>>>At the customer's insistence I'm using the IAR IDE, and interrupts are
>>>all f***ed up. Even the IAR demos don't work, and the register
>>>definitions in the ever-so-easy-to-find files don't match the
>>>documentation or, apparently, reality.
>>>
>>>I'm trying to figure out how much of this is me, how much is IAR, how
>>>much is TI, and how much is ARM.
>>>
>>>So if anyone has happened to use that particular set of tools with that
>>>processor (or if the symptoms sound right for _any_ IAR IDE with a
>>>Cortex M3), I'd like to hear how you solved the problems.
>>
>> That doesn't sound good (I know: Hello, Mr Obvious!). Check whether the
>> vector table offset register is getting set to the expected value.
>
> At the moment I'm pretending that interrupts were never invented, but
> I'll be doing something like that in my investigations.
>
> I just found out that the SPI register definitions are completely wrong
> -- it's like they took the definitions for a completely different
> processor and put them into the header file with my processor's name.
>
> Granted, it's an obscure high-temperature part I'm using (I can't
> remember the number off hand, SM470R1B1 or some such), but I pulled the
> data sheet for the TMS470R1B1 to double-check, and they match). I
> suspect that some serious bugs have managed to check themselves into the
> code tree without getting found.
>
> I suppose I should email them, give 'em a chance to do something about
> it. This is _frustrating_. When the customer said "we'll get the IAR
> system so we'll all be on the same IDE" I kinda rolled my eyes, because
> as far as I'm concerned an IDE is just training wheels that keep you up
> but wobbly, for as long as the project goes in the direction that the IDE
> vendor anticipated. But I figured it'd be about their speed, and after
> all we'd at least _get the damn thing working_.
Last time I used an IAR IDE it crashed when you expanded the main window
beyond 1024x768 :)
But that was 15 years ago, hopefully they have fixed that one :)
--
John Devereux
Reply by MK●October 25, 20112011-10-25
On 25/10/2011 07:16, Tim wrote:
> On Mon, 24 Oct 2011 16:23:58 -0400, Rich Webb wrote:
>
>> On Mon, 24 Oct 2011 13:27:40 -0500, Tim Wescott<tim@seemywebsite.com>
>> wrote:
>>
>>> Just starting to use the TMS470R1B1, which is a high-temp, high-rel
>>> processor with the ARM M3 core.
>>>
>>> At the customer's insistence I'm using the IAR IDE, and interrupts are
>>> all f***ed up. Even the IAR demos don't work, and the register
>>> definitions in the ever-so-easy-to-find files don't match the
>>> documentation or, apparently, reality.
>>>
>>> I'm trying to figure out how much of this is me, how much is IAR, how
>>> much is TI, and how much is ARM.
>>>
>>> So if anyone has happened to use that particular set of tools with that
>>> processor (or if the symptoms sound right for _any_ IAR IDE with a
>>> Cortex M3), I'd like to hear how you solved the problems.
>>
>> That doesn't sound good (I know: Hello, Mr Obvious!). Check whether the
>> vector table offset register is getting set to the expected value.
>
> At the moment I'm pretending that interrupts were never invented, but
> I'll be doing something like that in my investigations.
>
> I just found out that the SPI register definitions are completely wrong
> -- it's like they took the definitions for a completely different
> processor and put them into the header file with my processor's name.
>
> Granted, it's an obscure high-temperature part I'm using (I can't
> remember the number off hand, SM470R1B1 or some such), but I pulled the
> data sheet for the TMS470R1B1 to double-check, and they match). I
> suspect that some serious bugs have managed to check themselves into the
> code tree without getting found.
>
> I suppose I should email them, give 'em a chance to do something about
> it. This is _frustrating_. When the customer said "we'll get the IAR
> system so we'll all be on the same IDE" I kinda rolled my eyes, because
> as far as I'm concerned an IDE is just training wheels that keep you up
> but wobbly, for as long as the project goes in the direction that the IDE
> vendor anticipated. But I figured it'd be about their speed, and after
> all we'd at least _get the damn thing working_.
>
Hello Tim,
I couldn't find many references - a search on TI website comes up blank
- but it seems to be an ARM7 not a Cortex M3 - if your tools are set up
for an M3 there is no way it will work.
ARM7 interrupts are horrible (for embedded stuff) and completely different.
Michael Kellett
Reply by Tim●October 25, 20112011-10-25
On Mon, 24 Oct 2011 16:23:58 -0400, Rich Webb wrote:
> On Mon, 24 Oct 2011 13:27:40 -0500, Tim Wescott <tim@seemywebsite.com>
> wrote:
>
>>Just starting to use the TMS470R1B1, which is a high-temp, high-rel
>>processor with the ARM M3 core.
>>
>>At the customer's insistence I'm using the IAR IDE, and interrupts are
>>all f***ed up. Even the IAR demos don't work, and the register
>>definitions in the ever-so-easy-to-find files don't match the
>>documentation or, apparently, reality.
>>
>>I'm trying to figure out how much of this is me, how much is IAR, how
>>much is TI, and how much is ARM.
>>
>>So if anyone has happened to use that particular set of tools with that
>>processor (or if the symptoms sound right for _any_ IAR IDE with a
>>Cortex M3), I'd like to hear how you solved the problems.
>
> That doesn't sound good (I know: Hello, Mr Obvious!). Check whether the
> vector table offset register is getting set to the expected value.
At the moment I'm pretending that interrupts were never invented, but
I'll be doing something like that in my investigations.
I just found out that the SPI register definitions are completely wrong
-- it's like they took the definitions for a completely different
processor and put them into the header file with my processor's name.
Granted, it's an obscure high-temperature part I'm using (I can't
remember the number off hand, SM470R1B1 or some such), but I pulled the
data sheet for the TMS470R1B1 to double-check, and they match). I
suspect that some serious bugs have managed to check themselves into the
code tree without getting found.
I suppose I should email them, give 'em a chance to do something about
it. This is _frustrating_. When the customer said "we'll get the IAR
system so we'll all be on the same IDE" I kinda rolled my eyes, because
as far as I'm concerned an IDE is just training wheels that keep you up
but wobbly, for as long as the project goes in the direction that the IDE
vendor anticipated. But I figured it'd be about their speed, and after
all we'd at least _get the damn thing working_.
--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com
Reply by Arlet Ottens●October 25, 20112011-10-25
On 10/24/2011 10:23 PM, Rich Webb wrote:
> On Mon, 24 Oct 2011 13:27:40 -0500, Tim Wescott<tim@seemywebsite.com>
> wrote:
>
>> Just starting to use the TMS470R1B1, which is a high-temp, high-rel
>> processor with the ARM M3 core.
>>
>> At the customer's insistence I'm using the IAR IDE, and interrupts are
>> all f***ed up. Even the IAR demos don't work, and the register
>> definitions in the ever-so-easy-to-find files don't match the
>> documentation or, apparently, reality.
>>
>> I'm trying to figure out how much of this is me, how much is IAR, how
>> much is TI, and how much is ARM.
>>
>> So if anyone has happened to use that particular set of tools with that
>> processor (or if the symptoms sound right for _any_ IAR IDE with a Cortex
>> M3), I'd like to hear how you solved the problems.
>
> That doesn't sound good (I know: Hello, Mr Obvious!). Check whether the
> vector table offset register is getting set to the expected value. In
> the CM3 chips I'm mostly using now (STM32), the vector table offset
> register at 0xE000ED08 gets loaded with the actual (not remapped)
> address of the table in flash (0x08000000) (which gets automagically
> reflected to 0x00000000 on execution). This, or similar, ought to happen
> as pretty much the first set of instructions in the startup code.
>
Also, the vector table has strict alignment requirements. If you don't
align it properly, it may grab the wrong vector.
Reply by Rich Webb●October 24, 20112011-10-24
On Mon, 24 Oct 2011 13:27:40 -0500, Tim Wescott <tim@seemywebsite.com>
wrote:
>Just starting to use the TMS470R1B1, which is a high-temp, high-rel
>processor with the ARM M3 core.
>
>At the customer's insistence I'm using the IAR IDE, and interrupts are
>all f***ed up. Even the IAR demos don't work, and the register
>definitions in the ever-so-easy-to-find files don't match the
>documentation or, apparently, reality.
>
>I'm trying to figure out how much of this is me, how much is IAR, how
>much is TI, and how much is ARM.
>
>So if anyone has happened to use that particular set of tools with that
>processor (or if the symptoms sound right for _any_ IAR IDE with a Cortex
>M3), I'd like to hear how you solved the problems.
That doesn't sound good (I know: Hello, Mr Obvious!). Check whether the
vector table offset register is getting set to the expected value. In
the CM3 chips I'm mostly using now (STM32), the vector table offset
register at 0xE000ED08 gets loaded with the actual (not remapped)
address of the table in flash (0x08000000) (which gets automagically
reflected to 0x00000000 on execution). This, or similar, ought to happen
as pretty much the first set of instructions in the startup code.
--
Rich Webb Norfolk, VA