>
> I'm up to -02 now, when I get the courage I'll try -03 -- but I've
> changed the software since then, so it may or may not break, even if it
> was a flag related issue.
Thin twice - if you're not very tight on processing time,
-O2, or still better, -Os gives better results in embedded
controllers.
To look at the optimization, add -Wa,-ahlms=myfile.lst to
the gcc command line and look at the generated assembly
code.
You should also have most of the compiler warnings turned
on, to catch subtle blunders which bite in the higher
optimization levels.
--
Tauno Voipio
Reply by Nico Coesel●July 9, 20112011-07-09
David Brown <david.brown@removethis.hesbynett.no> wrote:
>On 07/07/11 18:40, Tim Wescott wrote:
>> On 07/07/2011 12:31 AM, David Brown wrote:
>>> On 07/07/2011 01:05, Tim Wescott wrote:
>>>> On 07/06/2011 03:12 PM, linnix wrote:
>>>>> On Jul 6, 2:56 pm, Tim Wescott<t...@seemywebsite.com> wrote:
>>>>>> On 07/06/2011 02:55 PM, Rob Gaddi wrote:
>>>>>>
>>>>>>
>>>>>>
>>
>> I'm up to -02 now, when I get the courage I'll try -03 -- but I've
>> changed the software since then, so it may or may not break, even if it
>> was a flag related issue.
>>
>
>When I think about it, I also had a Luminary Micro (or TI, as they are
>these days) Stellaris die on me for no obvious reason. I can't remember
>if we ever managed to resurrect it, or if we just swapped out the chip -
>I'll ask the other engineer tomorrow (if I remember). It certainly
>wasn't related to the program or flags - I think that is just a coincidence.
Suddenly I recall a co-worker had a similar problem with a Stellaris
chip. It is a very commnon problem and there is a work-around:
http://e2e.ti.com/support/microcontrollers/stellaris_arm_cortex-m3_microcontroller/f/471/p/45462/161777.aspx
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
Reply by krw...@att.bizzzzzzzzzzzz●July 9, 20112011-07-09
>Roberto Waltman <usenet@rwaltman.com> wrote:
>
>>Nico Coesel wrote:
>>>The best thing to do is to avoid JTAG for programming. The NXP parts
>>>have a serial port bootloader which always works.
>>
>>As other companies/cpu families. But in many cases you still need
>>JTAG for debugging, so the problem does not go away.
>
>Different discussion but you don't need JTAG for debugging. Stuff that
>isn't realtime is best developed on a PC so you can run large test
>benches against the code very fast. Besides that, affordable debugging
>tools for a PC are far more evolved than for embedded platforms.
"Realtime" isn't the issue. That, too, can be simulated (often better and
easier than "live"). The issue is hardware. Hardware, particularly hardware
that you don't have the design for, is a lot more difficult to simulate. It's
usually just not worth even an attempt, in an embedded system.
>If you need to debug realtime, JTAG is no option since you really
>don't want to halt an interrupt because before you stepped through the
>code, you'll have missed a boat load of other interrupts. Realtime
>debugging is best done by using counters in software or external
>signals to monitor state changes. When writing things which like PWM
>controllers it is best to write code which is safe by design.
Sure, the only real option is tracing back from a failure (or checkpoint).
Reply by Nico Coesel●July 9, 20112011-07-09
Roberto Waltman <usenet@rwaltman.com> wrote:
>Nico Coesel wrote:
>>The best thing to do is to avoid JTAG for programming. The NXP parts
>>have a serial port bootloader which always works.
>
>As other companies/cpu families. But in many cases you still need
>JTAG for debugging, so the problem does not go away.
Different discussion but you don't need JTAG for debugging. Stuff that
isn't realtime is best developed on a PC so you can run large test
benches against the code very fast. Besides that, affordable debugging
tools for a PC are far more evolved than for embedded platforms.
If you need to debug realtime, JTAG is no option since you really
don't want to halt an interrupt because before you stepped through the
code, you'll have missed a boat load of other interrupts. Realtime
debugging is best done by using counters in software or external
signals to monitor state changes. When writing things which like PWM
controllers it is best to write code which is safe by design.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
Reply by Paul●July 9, 20112011-07-09
In article <dbgf171rnng4qe28093jcpoa5hj3pcgpqn@4ax.com>,
krw@att.bizzzzzzzzzzzz says...
> >> >One possible solution is to have unconditional chip erase with 12V
on
> >> >VCC. �Unfortunately, it currently erase all hardware as well.
> >>
> >> Why would someone *WANT* such a thing?
> >
> >When there is no other way to recover the chip.
>
> Let me try again... Why would anyone, these days, design a chip that needed
> such a voltage just to erase the contents of memory?
>
> >> �Just use the same mechanism that's used to program the thing.
> >
> >When there is no other way.
>
> Then you've designed the wrong product.
>
> >> �...and today, why would *anyone* want to deal with
> >> 12V. �Any more than 3.3V (or sometimes even lower) gets to be a PITA.
> >
> >Only service people would ever use it, It has to be high enough not
> >to be applied accidentally.
>
> Nonsense. Just require an enable pin, or some such, before erase.
There is someone who ha snever had to chase down faults on enable or
worse still power rail sequencing. Many past devices had specific
requirements for the extra 12V programming rail, which required
external circuitry (even if simulated by software in a micro)
mainly to ensure VCC was stable before 12V or whatever programming
voltage, as often the protection for 12V on those pins ONLY worked
when VCC was stable otherwise you fried the device.
I have seen several faults on systems where the VCC was shorted or
came up slow by some other fault, which meant 12V programmed devices
fried as well!
Great way NOT to recover devices.
--
Paul Carpenter | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate
Reply by krw...@att.bizzzzzzzzzzzz●July 8, 20112011-07-08
>On Jul 8, 3:51�pm, "k...@att.bizzzzzzzzzzzz" <k...@att.bizzzzzzzzzzzz>
>wrote:
>> On Fri, 8 Jul 2011 12:22:51 -0700 (PDT), linnix <m...@linnix.info-for.us> wrote:
>> >On Jul 8, 11:59�am, Rich Webb <bbew...@mapson.nozirev.ten> wrote:
>> >> On Fri, 8 Jul 2011 10:57:32 -0700 (PDT), linnix <m...@linnix.info-for.us>
>> >> wrote:
>>
>> >> >On Jul 8, 8:41 am, Roberto Waltman <use...@rwaltman.com> wrote:
>> >> >> Nico Coesel wrote:
>> >> >> >The best thing to do is to avoid JTAG for programming. The NXP parts
>> >> >> >have a serial port bootloader which always works.
>>
>> >> >> As other companies/cpu families. But in many cases you still need
>> >> >> JTAG for debugging, so the problem does not go away.
>> >> >> --
>>
>> >> >AVR has parallel (always work), I2C and sometimes JTAG.
>> >> >PIC24 has 3 sets of I2C programmings.
>> >> >ARM is kind of weak, usually just JTAG/SWD.
>>
>> >> >I guess ARM is for large volume and you can just throw away some
>> >> >chips.
>>
>> >> Usually (grand, sweeping generalization; usually = "the ARM chips that
>> >> I'm familiar with" �;-) there is a pin or pins that can be set/reset
>> >> when the processor comes out of POR that enables a serial boot loader.
>> >> That method is fairly bulletproof but can be a PITA if that UART has
>> >> application hardware hanging off of it, or if the pins in question are
>> >> shared with GPIO.
>>
>> >Fine for development, but deployment units don't always want to have
>> >bootloader loaded. �Imagine all those customer support calls: �What do
>> >you mean checking bootloader? �What is a bootloader? �Do I need to
>> >kick it with my boot to load it?
>>
>> No, the user doesn't see the bootloader, any more than a PC user "sees" the
>> BIOS bootloader.
>>
>> >One possible solution is to have unconditional chip erase with 12V on
>> >VCC. �Unfortunately, it currently erase all hardware as well.
>>
>> Why would someone *WANT* such a thing?
>
>When there is no other way to recover the chip.
Let me try again... Why would anyone, these days, design a chip that needed
such a voltage just to erase the contents of memory?
>> �Just use the same mechanism that's used to program the thing.
>
>When there is no other way.
Then you've designed the wrong product.
>> �...and today, why would *anyone* want to deal with
>> 12V. �Any more than 3.3V (or sometimes even lower) gets to be a PITA.
>
>Only service people would ever use it, It has to be high enough not
>to be applied accidentally.
Nonsense. Just require an enable pin, or some such, before erase.
Reply by linnix●July 8, 20112011-07-08
On Jul 8, 3:51=A0pm, "k...@att.bizzzzzzzzzzzz" <k...@att.bizzzzzzzzzzzz>
wrote:
> >> wrote:
>
> >> >On Jul 8, 8:41 am, Roberto Waltman <use...@rwaltman.com> wrote:
> >> >> Nico Coesel wrote:
> >> >> >The best thing to do is to avoid JTAG for programming. The NXP par=
ts
> >> >> >have a serial port bootloader which always works.
>
> >> >> As other companies/cpu families. But in many cases you still need
> >> >> JTAG for debugging, so the problem does not go away.
> >> >> --
>
> >> >AVR has parallel (always work), I2C and sometimes JTAG.
> >> >PIC24 has 3 sets of I2C programmings.
> >> >ARM is kind of weak, usually just JTAG/SWD.
>
> >> >I guess ARM is for large volume and you can just throw away some
> >> >chips.
>
> >> Usually (grand, sweeping generalization; usually =3D "the ARM chips th=
at
> >> I'm familiar with" =A0;-) there is a pin or pins that can be set/reset
> >> when the processor comes out of POR that enables a serial boot loader.
> >> That method is fairly bulletproof but can be a PITA if that UART has
> >> application hardware hanging off of it, or if the pins in question are
> >> shared with GPIO.
>
> >Fine for development, but deployment units don't always want to have
> >bootloader loaded. =A0Imagine all those customer support calls: =A0What =
do
> >you mean checking bootloader? =A0What is a bootloader? =A0Do I need to
> >kick it with my boot to load it?
>
> No, the user doesn't see the bootloader, any more than a PC user "sees" t=
he
> BIOS bootloader.
>
> >One possible solution is to have unconditional chip erase with 12V on
> >VCC. =A0Unfortunately, it currently erase all hardware as well.
>
> Why would someone *WANT* such a thing?
When there is no other way to recover the chip.
> =A0Just use the same mechanism that's used to program the thing.
When there is no other way.
> =A0...and today, why would *anyone* want to deal with
> 12V. =A0Any more than 3.3V (or sometimes even lower) gets to be a PITA.
Only service people would ever use it, It has to be high enough not
to be applied accidentally.
Reply by krw...@att.bizzzzzzzzzzzz●July 8, 20112011-07-08
>On Jul 8, 11:59�am, Rich Webb <bbew...@mapson.nozirev.ten> wrote:
>> On Fri, 8 Jul 2011 10:57:32 -0700 (PDT), linnix <m...@linnix.info-for.us>
>> wrote:
>>
>> >On Jul 8, 8:41 am, Roberto Waltman <use...@rwaltman.com> wrote:
>> >> Nico Coesel wrote:
>> >> >The best thing to do is to avoid JTAG for programming. The NXP parts
>> >> >have a serial port bootloader which always works.
>>
>> >> As other companies/cpu families. But in many cases you still need
>> >> JTAG for debugging, so the problem does not go away.
>> >> --
>>
>> >AVR has parallel (always work), I2C and sometimes JTAG.
>> >PIC24 has 3 sets of I2C programmings.
>> >ARM is kind of weak, usually just JTAG/SWD.
>>
>> >I guess ARM is for large volume and you can just throw away some
>> >chips.
>>
>> Usually (grand, sweeping generalization; usually = "the ARM chips that
>> I'm familiar with" �;-) there is a pin or pins that can be set/reset
>> when the processor comes out of POR that enables a serial boot loader.
>> That method is fairly bulletproof but can be a PITA if that UART has
>> application hardware hanging off of it, or if the pins in question are
>> shared with GPIO.
>
>Fine for development, but deployment units don't always want to have
>bootloader loaded. Imagine all those customer support calls: What do
>you mean checking bootloader? What is a bootloader? Do I need to
>kick it with my boot to load it?
No, the user doesn't see the bootloader, any more than a PC user "sees" the
BIOS bootloader.
>One possible solution is to have unconditional chip erase with 12V on
>VCC. Unfortunately, it currently erase all hardware as well.
Why would someone *WANT* such a thing? Just use the same mechanism that's
used to program the thing. ...and today, why would *anyone* want to deal with
12V. Any more than 3.3V (or sometimes even lower) gets to be a PITA.
>On Jul 8, 11:59�am, Rich Webb <bbew...@mapson.nozirev.ten> wrote:
>> On Fri, 8 Jul 2011 10:57:32 -0700 (PDT), linnix <m...@linnix.info-for.us>
>> wrote:
>>
>> >On Jul 8, 8:41 am, Roberto Waltman <use...@rwaltman.com> wrote:
>> >> Nico Coesel wrote:
>> >> >The best thing to do is to avoid JTAG for programming. The NXP parts
>> >> >have a serial port bootloader which always works.
>>
>> >> As other companies/cpu families. But in many cases you still need
>> >> JTAG for debugging, so the problem does not go away.
>> >> --
>>
>> >AVR has parallel (always work), I2C and sometimes JTAG.
>> >PIC24 has 3 sets of I2C programmings.
>> >ARM is kind of weak, usually just JTAG/SWD.
>>
>> >I guess ARM is for large volume and you can just throw away some
>> >chips.
>>
>> Usually (grand, sweeping generalization; usually = "the ARM chips that
>> I'm familiar with" �;-) there is a pin or pins that can be set/reset
>> when the processor comes out of POR that enables a serial boot loader.
>> That method is fairly bulletproof but can be a PITA if that UART has
>> application hardware hanging off of it, or if the pins in question are
>> shared with GPIO.
>
>Fine for development, but deployment units don't always want to have
>bootloader loaded.
It's always there, in ROM. LPC chips usually (see above) always vector
to the bootloader after reset. Application code is started by the
bootloader. ST's vector out of reset to application flash or boot ROM
depending on pin strapping.
> Imagine all those customer support calls: What do
>you mean checking bootloader? What is a bootloader? Do I need to
>kick it with my boot to load it?
Indeed, having the bootloader take control in an end-user's device would
be a Bad Thing.
--
Rich Webb Norfolk, VA
Reply by linnix●July 8, 20112011-07-08
On Jul 8, 11:59=A0am, Rich Webb <bbew...@mapson.nozirev.ten> wrote:
> On Fri, 8 Jul 2011 10:57:32 -0700 (PDT), linnix <m...@linnix.info-for.us>
> wrote:
>
> >On Jul 8, 8:41 am, Roberto Waltman <use...@rwaltman.com> wrote:
> >> Nico Coesel wrote:
> >> >The best thing to do is to avoid JTAG for programming. The NXP parts
> >> >have a serial port bootloader which always works.
>
> >> As other companies/cpu families. But in many cases you still need
> >> JTAG for debugging, so the problem does not go away.
> >> --
>
> >AVR has parallel (always work), I2C and sometimes JTAG.
> >PIC24 has 3 sets of I2C programmings.
> >ARM is kind of weak, usually just JTAG/SWD.
>
> >I guess ARM is for large volume and you can just throw away some
> >chips.
>
> Usually (grand, sweeping generalization; usually =3D "the ARM chips that
> I'm familiar with" =A0;-) there is a pin or pins that can be set/reset
> when the processor comes out of POR that enables a serial boot loader.
> That method is fairly bulletproof but can be a PITA if that UART has
> application hardware hanging off of it, or if the pins in question are
> shared with GPIO.
Fine for development, but deployment units don't always want to have
bootloader loaded. Imagine all those customer support calls: What do
you mean checking bootloader? What is a bootloader? Do I need to
kick it with my boot to load it?
One possible solution is to have unconditional chip erase with 12V on
VCC. Unfortunately, it currently erase all hardware as well.