Failure to Launch

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Greetings,

 

It would seem that the eval boards should come with debugger targets already installed.  I would expect that connecting an Eval card to a PC with software you should be able to download and execute code.  It would be nice to download over USB or Ethernet.  And it seems that a JTAG ICE is needed.  Not ideal, but OK.

 

Got the EVK1100, Atmel-ICE and the extra kit with the 50mil to 100 mill adapter (thanks).  Set up Studio 6 and built the EVK1100 demo application (confirmed build worked with the simulator).  Selected Tools- Device Programming, selected JTAG-ICE and clicked Interface 'APPLY' (bit tricky there).  Did a fresh build and clicked 'DEBUG' 'START Debugging'.  The debugger cycles a bit and reports "Error: Saving to device failed".

 

Poking about on the net suggests that the ICE is having a hard time talking to the target.

 

Any suggestions on where to look next?

Last Edited: Sat. Jan 28, 2017 - 12:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

UPDATE: need to properly set erase chip...

It seems that the default was in conflict with the fuse settings.

Last Edited: Sat. Jan 28, 2017 - 12:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Trivet wrote:
It would seem that the eval boards should come with debugger targets already installed

Quote:
I would expect that connecting an Eval card to a PC with software you should be able to download and execute code

Where did you get that expectation?

 

While it is, indeed, the case that most newer evaluation/development boards do now come with on-board debug adaptors, that has not always been the case.

 

Quote:
And it seems that a JTAG ICE is needed

A JTAG ICE is one option - but not the only option.

 

Again, the "traditional" approach has been to have a separate debug/programming adaptor or "probe" - but newer kits do tend to have it integrated.

 

It should be noted that Atmel were quite late to cotton-on to this trend.

 

Quote:
Not ideal

 

That depends on how you look at it!

 

Clearly, including the debug adaptor on the board increases the cost & complexity of the board.

 

It can also have other drawbacks; eg,

  • on some boards, it means that you can only run at 3.3V - you can't (easily) evaluate the performance at other voltages.
  • having the debugger permanently connected can be a problem when trying to evaluat really low power modes - you're not quite sure how much leakage there might be to the debugger
  • etc, etc, ...

 

And, of course, when you come to dsesign your own board, you won't be putting a debug adaptor on that - so you will have to buy one at some point anyhow.

 

What target device are you actually using?

 

Have you looked to see if there is a board available with integral debug? eg, an Xplained-Pro board?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

>> I would expect that connecting an Eval card to a PC with software you should be able to download and execute code

> Where did you get that expectation?

> While it is, indeed, the case that most newer evaluation/development boards do now come with on-board debug adaptors, that has not always been the case.

 

Some time ago I used this new "AVR" embedded chip on a project.  It was a breath of fresh air.  The tools worked out of the box, complete with debug target on die.  The target needed little support, and performed admirably.  It came from a group in Norway, started by a couple of students...

 

The same processor, generations later is in the Arduino, which also is a breath of fresh air.

 

> What target device are you actually using?

 

The EVK1100 and looking at others

 

UPDATE: it seems that the XMEGA D4 is well suited... small footprint, no crypto restrictions...

 

> Have you looked to see if there is a board available with integral debug? eg, an Xplained-Pro board?

 

Yes, I have some of the Xplained boards (ATMEL ATXMEGAC3-XPLD, XMEGA-C3 XPLAINED & EVK1100).

 

> What target device are you actually using?

 

That is not clear.  Evaluating the parts is an ongoing task.

 

I liked the AVR32UC3B (not the name), but the I/O ring running on a slower clock makes for erratic GPIO timing (the application calls for I2C implemented in GPIO).

 

The ATxmega384C3 seems sufficient so far.

 

[Forum feedback provided heads up on a few things, like ITAR restrictions (thanks)]

 

Any comments or heckling welcome! ;^)

Last Edited: Sat. Aug 12, 2017 - 09:48 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Trivet wrote:
I have been going from one part to another, looking for why this one is unacceptable

Which one(s) have you eliminated so far? (so that people don't waste time suggesting ones that you've already discarded)

 

Trivet wrote:
the CPUs tend to need 5 volt to operate at 16 MHz (ugh).

So have you looked at the ARM-based offerings?

 

eg, the SAM D2x can do 48 MHz at 3V ...

Last Edited: Sat. Apr 18, 2015 - 07:49 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> (so that people don't waste time suggesting ones that you've already discarded)

 

[the application is to manage scores of sensors operating at 3.3 volt, over I2C @ 400 KHz, that produce 64 bits of raw data every millisecond; there is a need for ~100 I2C bus clocks with overhead per device sample set.  A single I2C bus is insufficient to offload the data fast enough.  The intended solution is to implement 8 or 16 I2C buses using GPIOs.  Timing of when GPIO operations occur is critical.  The uplink to the host will post about 600 bytes every cycle, ~5 Mbps upstream]

 

> Which [CPUs] have you eliminated so far?

 

1) Anything with a crypto core... in case there is a desire to export the device.

 

2) The AVR32s all seem to have issues with the I/O ring.  The operations (at 15 MHz) seem to revolve around 160ns GPIO (320 ns minimum resolution of a waveform) and seems to gobble CPU clocks while the I/O is in process (this may be a configuration issue). [code running on EVK-1100/AT32UC3A, simulated on AT32UC3B0].

 

3) The USB90 looks good, the peripherals are 3.3 volt, so to meet the performance requirements there may be a voltage level issue if running at 8-16 MHz and may not be fast enough.

 

4) The Mega family that does not have native USB; does not seem to have enough upstream communications bandwidth.

 

5) Have not looked at the ARMs yet... but they all seem to have the I/O ring timing problem (see #1).

 

 

Thanks for any feedback!

Last Edited: Sat. Aug 12, 2017 - 09:53 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sounds like a CPLD or FPGA might be a better fit here ... ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Curious... I posted on another list (touching on the idea of hardware/software co-design) that conventional thought would put an FPGA in the design.  It is an option, would make the design a lot more complicated and increase cost.

 

The Xmega devices with integrated USB seems sufficient for all IO, computation, management and communications.

Last Edited: Fri. Aug 11, 2017 - 11:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Epilog:

 

1) The ATMEL site processor selector is a good tool.  The Microchip version is sufficient.

 

2) Processors with I/O buses that are not run on the core clock can result in GPIO jitter and can be bandwidth limiting.

 

3) The AVR processors with USB have an optional boot loader that can be ordered from the factory or programmed in.

 

4) An FPGA is well suited to implement complex buses, but with careful programming the AVR is sufficient.

    [the design called for 29 I/Os including debug, AVR in a 44 QFP provided ample resources, for less than $3 qty 1 & no external support]

 

5) The eval boards and kits are a great way to get started.  In the end custom code is generally preferable.

     The now defunct X-plained devices are a wealth of good information.

 

6) The ATMEL ICE unit is well integrated into the IDE and manages the proprietary PDI/SPI/JTAG debug interface.

 

7) Documentation overall is a bit chaotic and one needs to infer information from documentation for other devices.
 

Thanks for the online and offline assistance!

Last Edited: Sat. Aug 12, 2017 - 09:58 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

>I do have 0ne of the Xplained boards

 

Note that "Xplained" and "Xplained Pro" are distinctively different. No on-board debugger on the former as far as I know. 

Happy 75th anniversary to one of the best movies ever made! Rick Blane [Bogart]: "Of all the gin joints, in all the towns, in all the world, she walks into mine."

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
No on-board debugger on the former

Correct. That is probably the key differentiator.

 

I think the standard header layout is also different?

 

Not sure that the plain XPlained had the "auto-detect" feature for Studio?

 

XPlained is definitely the previous generation - so some older chips have XPlained, while newer ones have the -Pro