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: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> On 7/6/2011 2:32 PM, Tim Wescott wrote: >>>>>> I just replaced the "-O0" in my makefile with "-O3", and as soon as >>>>>> the >>>>>> code ran the JTAG debugger stopped working -- it reports "all >>>>>> ones" on >>>>>> the JTAG chain when it tries to connect. >>>> >>>>>> Gnu tool chain. >>>> >>>>>> Has anyone had this happen? Any clues on how to get functionality >>>>>> back? >>>>>> I suspect that I just need to replace the chip -- but that's a >>>>>> pain in >>>>>> the backside, and I don't want to do it too many times!! I'm going to >>>>>> put an escape hatch in the software, probably to come on before >>>>>> anything >>>>>> else at all is alive, but better ideas are welcome. >>>> >>>>> Haven't played any with the Luminary chips, but I know that on the NXP >>>>> Cortex M3s there's a problem where if you get the PLL misconfigured it >>>>> would break the JTAG link. Meaning if you flashed in code that broke >>>>> the >>>>> PLL, you can't get it back. >>>> >>>>> It's possible (?) that the Luminary parts have a similar flaw, and >>>>> that >>>>> optimization broke your PLL init code, maybe. On the NXPs, one of the >>>>> pins doubles as a service boot mode pin that could be used in a >>>>> pinch to >>>>> get you out of that particular jam. No idea whether any of this >>>>> correlates to the Luminary. >>>> >>>> I've been down that particular road before, but it's not happening >>>> -- my >>>> last software load is in there and talking on the serial ports. So not >>>> only is the PLL not broken, but it's going the right speed. >>>> >>> >>> Check to make sure you are not accidentally re-assigning the JTAG pins >>> to GPIO. Port B& C are shared with JTAG/SWD. Yes, escape pin (skip >>> init if grounded) is a good idea, if you have to use port B& C. >>> >> The weird thing is that this happened after I changed the optimization >> flag on the compiler -- I didn't touch the code. >> >> Granted, I _was_ half expecting to break something, or at least make >> debugging difficult. I _wasn't_ expecting to mess up with JTAG!! >> > > It would be worth taking a step back and treating the compiler flag > changes as a coincidence. What then could have caused the JTAG to stop > working? Go through the usual suspects (power spikes, static, bits of > wire under the board, Windows playing silly buggers with USB drivers, > etc.).I did do all of that -- no help. I am quite sure that Windows didn't bugger up the USB drivers, though -- I'm on a Linux machine! I broke down late yesterday afternoon (after going off and doing some honey-do tasks) and swapped out the chip. Everything works fine -- including the brand new escape hatch which I've put into my startup code before _anything else_ happens. So as long as that code gets into the machine undisturbed, I'll be able to do a save. 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. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.html
Luminary JTAG disabled by optimizations? WTF??
Started by ●July 6, 2011
Reply by ●July 7, 20112011-07-07
Reply by ●July 7, 20112011-07-07
Rich Webb <bbew.ar@mapson.nozirev.ten> wrote:>On Thu, 07 Jul 2011 13:21:00 +0100, John Devereux <john@devereux.me.uk> >wrote: > >>Tim Wescott <tim@seemywebsite.com> writes: >> >>> I just replaced the "-O0" in my makefile with "-O3", and as soon as >>> the code ran the JTAG debugger stopped working -- it reports "all >>> ones" on the JTAG chain when it tries to connect. >>> >>> Gnu tool chain. >>> >>> Has anyone had this happen? Any clues on how to get functionality >>> back? >> >>I have had similar things happen on other chips - usually it's because I >>broke the PLL setup or, last time, assigned the JTAG pins to other >>functions by mistake :) >> >>You may be able to tell the CPU to enter a different boot mode by >>pulling a pin low etc. It will then typically crash or wait in some >>loop, but at least it won't execute the code of death you have put there >>somehow :) >> >>> I suspect that I just need to replace the chip -- but that's a >>> pain in the backside, and I don't want to do it too many times!! I'm >>> going to put an escape hatch in the software, probably to come on >>> before anything else at all is alive, but better ideas are welcome. >> >>I don't know if you are using openocd? On NXP parts it is in fact >>possible to stop at the internal (boot code) reset vector, although the >>standard config files assume you cannot so they instead always run your >>code for some programmed time. You might want to look into this aspect >>with your own parts. > >It may also help to try a different burner environment. I had one >LPC2k-series chip where I neglected to check whether a JTAG adapter was >plugged in before enabling the watchdog. The watchdog reset time was >faster than some cycle time under JTAG so it would always reset before I >could get new code onto it. Bummer. But, I also had a Scarabeus JTAG >dongle (from Kristech.eu, old, no longer available) and it was able to >get in and get control fast enough to save the day. Something to try >there's a different debugger/loader or JTAG dongle available.The best thing to do is to avoid JTAG for programming. The NXP parts have a serial port bootloader which always works. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------
Reply by ●July 7, 20112011-07-07
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: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> On 7/6/2011 2:32 PM, Tim Wescott wrote: >>>>>>> I just replaced the "-O0" in my makefile with "-O3", and as soon as >>>>>>> the >>>>>>> code ran the JTAG debugger stopped working -- it reports "all >>>>>>> ones" on >>>>>>> the JTAG chain when it tries to connect. >>>>> >>>>>>> Gnu tool chain. >>>>> >>>>>>> Has anyone had this happen? Any clues on how to get functionality >>>>>>> back? >>>>>>> I suspect that I just need to replace the chip -- but that's a >>>>>>> pain in >>>>>>> the backside, and I don't want to do it too many times!! I'm >>>>>>> going to >>>>>>> put an escape hatch in the software, probably to come on before >>>>>>> anything >>>>>>> else at all is alive, but better ideas are welcome. >>>>> >>>>>> Haven't played any with the Luminary chips, but I know that on the >>>>>> NXP >>>>>> Cortex M3s there's a problem where if you get the PLL >>>>>> misconfigured it >>>>>> would break the JTAG link. Meaning if you flashed in code that broke >>>>>> the >>>>>> PLL, you can't get it back. >>>>> >>>>>> It's possible (?) that the Luminary parts have a similar flaw, and >>>>>> that >>>>>> optimization broke your PLL init code, maybe. On the NXPs, one of the >>>>>> pins doubles as a service boot mode pin that could be used in a >>>>>> pinch to >>>>>> get you out of that particular jam. No idea whether any of this >>>>>> correlates to the Luminary. >>>>> >>>>> I've been down that particular road before, but it's not happening >>>>> -- my >>>>> last software load is in there and talking on the serial ports. So not >>>>> only is the PLL not broken, but it's going the right speed. >>>>> >>>> >>>> Check to make sure you are not accidentally re-assigning the JTAG pins >>>> to GPIO. Port B& C are shared with JTAG/SWD. Yes, escape pin (skip >>>> init if grounded) is a good idea, if you have to use port B& C. >>>> >>> The weird thing is that this happened after I changed the optimization >>> flag on the compiler -- I didn't touch the code. >>> >>> Granted, I _was_ half expecting to break something, or at least make >>> debugging difficult. I _wasn't_ expecting to mess up with JTAG!! >>> >> >> It would be worth taking a step back and treating the compiler flag >> changes as a coincidence. What then could have caused the JTAG to stop >> working? Go through the usual suspects (power spikes, static, bits of >> wire under the board, Windows playing silly buggers with USB drivers, >> etc.). > > I did do all of that -- no help. I am quite sure that Windows didn't > bugger up the USB drivers, though -- I'm on a Linux machine! > > I broke down late yesterday afternoon (after going off and doing some > honey-do tasks) and swapped out the chip. Everything works fine -- > including the brand new escape hatch which I've put into my startup code > before _anything else_ happens. So as long as that code gets into the > machine undisturbed, I'll be able to do a save. > > 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. However, it's seldom worth going for -O3 - most embedded systems are compiled with -Os which puts more emphasis on smaller code. Theoretically, -O3 is faster for some things - but often, even on "big" processors, the increased code size and therefore decreased cache hits make the code slower than -O2 or -Os. So the general rule is -O2 if you've plenty of cache and memory bandwidth, or -Os if you want smaller code. For particular parts of your code, you may want extra effort (maybe loop unrolling in a critical loop, for example) - enable extra optimisations for that part only. You can do that easily with recent gcc's, using optimisation function attributes or pragmas.
Reply by ●July 8, 20112011-07-08
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. -- Roberto Waltman [ Please reply to the group. Return address is invalid ]
Reply by ●July 8, 20112011-07-08
On Jul 8, 8:41=A0am, 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. =A0But 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.
Reply by ●July 8, 20112011-07-08
On Fri, 8 Jul 2011 10:57:32 -0700 (PDT), linnix <me@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. -- Rich Webb Norfolk, VA
Reply by ●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.
Reply by ●July 8, 20112011-07-08
On Fri, 8 Jul 2011 12:22:51 -0700 (PDT), linnix <me@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.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 ●July 8, 20112011-07-08
On Fri, 8 Jul 2011 12:22:51 -0700 (PDT), linnix <me@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? 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.
Reply by ●July 8, 20112011-07-08
On Jul 8, 3:51=A0pm, "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=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 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.
