EmbeddedRelated.com
Forums

Luminary JTAG disabled by optimizations? WTF??

Started by Tim Wescott July 6, 2011
On Fri, 8 Jul 2011 17:56:07 -0700 (PDT), linnix <me@linnix.info-for.us> wrote:

>On Jul 8, 3:51&#4294967295;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&#4294967295;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" &#4294967295;;-) 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. &#4294967295;Imagine all those customer support calls: &#4294967295;What do >> >you mean checking bootloader? &#4294967295;What is a bootloader? &#4294967295;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. &#4294967295;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?
>> &#4294967295;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.
>> &#4294967295;...and today, why would *anyone* want to deal with >> 12V. &#4294967295;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.
In article <dbgf171rnng4qe28093jcpoa5hj3pcgpqn@4ax.com>, 
krw@att.bizzzzzzzzzzzz says...
> > On Fri, 8 Jul 2011 17:56:07 -0700 (PDT), linnix <me@linnix.info-for.us> wrote: > > >On Jul 8, 3:51&#4294967295;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:
....
> >> >One possible solution is to have unconditional chip erase with 12V
on
> >> >VCC. &#4294967295;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? > > >> &#4294967295;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. > > >> &#4294967295;...and today, why would *anyone* want to deal with > >> 12V. &#4294967295;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
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=.) --------------------------------------------------------------
On Sat, 09 Jul 2011 18:29:55 GMT, nico@puntnl.niks (Nico Coesel) wrote:

>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).
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=.) --------------------------------------------------------------
On 7.7.11 7:40 , Tim Wescott 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.
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