Luminary JTAG disabled by optimizations? WTF??

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.

--
Tim Wescott
Wescott Design Services
 Click to see the full signature
Reply to
Tim Wescott
Loading thread data ...

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.

--
Rob Gaddi, Highland Technology
Email address is currently out of order
Reply to
Rob Gaddi

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.

--
Tim Wescott
Wescott Design Services
 Click to see the full signature
Reply to
Tim Wescott

e
?

ng

e
o

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.

Reply to
linnix

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!!

--
Tim Wescott
Wescott Design Services
 Click to see the full signature
Reply to
Tim Wescott

If I had to guess, I'd guess that maybe there's a variable declaration somewhere (e.g. for a memory-mapped register) which is missing a "volatile" clause, or there are some accesses to the JTAG registers which need explicit memory-barrier instructions/calls in place.

In this situation, turning on code optimization might have caused the compiler to either optimize away certain stores or reads which it considered to be redundant, or might have caused stores or reads to be re-ordered in a way which breaks the logic.

Dump out the generated machine code for your JTAG setup and access logic, for the non-optimized and fully-optimized cases. I think you'll find a smoking absence-of-a-gun in the optimized case (i.e. "missing" or reorganized instructions or accesses, which would have no ill effect on the semantics if the variables were normal memory locations, but foul things up badly for memory-mapped I/O registers).

--
Dave Platt                                    AE6EO
Friends of Jade Warrior home page:  http://www.radagast.org/jade-warrior
 Click to see the full signature
Reply to
Dave Platt

The problem is that the software can't do anything with JTAG (except break it). JTAG is a hardware function that can have its pins stolen by software, but which software cannot otherwise touch.

--
Tim Wescott
Control system and signal processing consulting
 Click to see the full signature
Reply to
Tim

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.).

Reply to
David Brown

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 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.

--

John Devereux
Reply to
John Devereux

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.

--
Rich Webb     Norfolk, VA
Reply to
Rich Webb

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
 Click to see the full signature
Reply to
Tim Wescott

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...
 Click to see the full signature
Reply to
Nico Coesel

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 to
David Brown

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 to
Roberto Waltman

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 to
linnix

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 to
Rich Webb

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 to
linnix

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.

Indeed, having the bootloader take control in an end-user's device would be a Bad Thing.

--
Rich Webb     Norfolk, VA
Reply to
Rich Webb

No, the user doesn't see the bootloader, any more than a PC user "sees" the BIOS bootloader.

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 to
krw

ts

at

do

he

When there is no other way to recover the chip.

When there is no other way.

Only service people would ever use it, It has to be high enough not to be applied accidentally.

Reply to
linnix

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.