Xplained boards (UC3B iface chip), avrdude, UART-USB gateway

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

I have two new Xplained boards: an mega1284P and an xmega128a1.

Lot's of searching has failed to give me a definitive answer:
Is there a possibility of programming via avrdude through the existing UC3B chip's bootloader/serial interface on the boards?

I could do it through a JTAGICEMKII or an STK600 jtag, or a cable and an AVRISPMK2, but it would be convenient for field upgrade on this project to be able to use the USB interface.

It seems the LUFA bridge was primarily for the older AT90 chips?

I'm using linux with avrdude 5.11.1.

Last Edited: Sat. Dec 1, 2012 - 12:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AVR370: MEGA-1284P Xplained Getting Started Guide says the bootloader uses "avrosp"
AVR1927: XMEGA-128A1 Xplained Getting Started Guide says Batchisp.

So the 1284 is very straightforward. i.e. "-c avr911"
The xmega may take a bit of experimentation. e.g. avr911

I have got an Xmega board. So if you still have trouble, I can do some experiments myself.

David.

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

Hmmm. BOTH the xmega and 1284P boards come up under 'lsusb' as:

Bus 001 Device 025: ID 03eb:2122 Atmel Corp. XMEGA-A1 Explained evaluation kit

and show from 'dmesg|tail' as:
991396.196697] usb 1-1.3: USB disconnect, device number 24
[991424.752989] usb 1-1.3: new full-speed USB device number 25 using ehci_hcd
[991424.840236] usb 1-1.3: New USB device found, idVendor=03eb, idProduct=2122
[991424.840247] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[991424.840253] usb 1-1.3: Product: XPLAINED CDC
[991424.840258] usb 1-1.3: Manufacturer: ATMEL
[991424.840262] usb 1-1.3: SerialNumber: 124904001028
[991424.840914] cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device

But avrdude doesn't like either board:
$ sudo avrdude -p x128a1 -P /dev/ttyACM0 -c avr911 -t

Connecting to programmer: .avrdude: butterfly_recv(): programmer is not responding

$ sudo avrdude -p m1284p -P /dev/ttyACM0 -c avr911 -t

Connecting to programmer: .avrdude: butterfly_recv(): programmer is not responding

Or, after:
$ sudo modprobe usbserial vendor=0x03eb product=0x2122
$ sudo avrdude -p x128a1 -P usb -c avr911 -t
avrdude: ser_open(): can't open device "usb": No such file or directory
Eavrdude: butterfly_recv(): programmer is not responding

And yes, that 'E' before avrdude came up in the response!

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

avr911 needs a COM port. e.g. /dev/ttyUSB0
I don't know /dev/ttyACM0

I would definitely try different baud rates.

I will fish out my XMEGA Xplained board and see what happens.

David.

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

I only have the XMEGA128A1 Xplained board.

It does not respond to avrdude -c avr911

It does respond to Flip and to Batchisp.
You can obviously run Flip on Linux. I presume that Batchisp is the same thing, but from the command line.

I had to install the CDC device driver.
I had to install the bootloader on the x128a1

It is an absolute pain to 'enter bootloader'
However, once entered, you can program from an AS6 'post build' command.

I had previously used the Xplained board on another PC and only with JTAG. I was not aware that I had ever erased the bootloader. Perhaps it came out of the box without any bootloader !

I am appalled by the quality of the AVR1924 and AVR1927 app notes. A beginner would really struggle with the bootloader.

How have you got on with the m1284 bootloader ?

David.

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

Various baud rates didn't help at all.

As for ttyACM0 it is most often related to modems, but some USB comm-port devices come up that way.

I just tried my AT32UC3C-EK board and it enumerates to ACM0 too. Kermit likes it well enough...but the one on the Xplained board is useless. Dog-slow, and doesn't pass the transmitted characters through from the Xmega.

Apparantly the UC3B yanks the RX-line to the Xmega high so USART input via J4 to the Xmega won't work. Once I switched to J1 and port F comms it worked fine.

I've spent most of my time on the Xmega board, but the 1284p board acts similarly.

I got flip.3.2.1 to run via:

java -jar flip.jar

but Device->Select only shows AT89,90 devices, so I probably need to set up udev rules.

Trying batchisp3.sh it complained about no jvm.dll, so I searched around a while, and found a good tutorial on setting it up:
http://sourceforge.net/apps/trac...

Now it gets as far as Opening port....AtLibUsbDfu: 3EB 2FF6 no device present.
which is what the udev rules say to use, but the Xplained comes up as 3EB 2122 so I either need another bootloader, or I need to change the rules.

I haven't found Atmel's Linux support to be very robust. Back on my ARM SAM7X project, their SAM-BA boot loader worked only after they sent me a patched executable, but failed again after a kernel update.

I ended up using Andrew Sterian's SAM-I-AM python program which was awesome. As is avrdude when the hardware is supported.

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

Even with the current Flip, you need to add the ATxmega128a1.xml file to the Flip part descriptions.
Flip 3.2.1 is well out of date.

Surely you read the AVR1924 and AVR1927 app notes.
You get the relevant xml and hex files from avr1927.zip

I suggest that you get Flip working on Linux. After all, AT89 chips, AT90USB, ATmegaxxU chips all use Flip.

Did avrdude -c avr911 work with the m1284 ?

AVR1605 (I think) is an avr911 bootloader for the Xmega. However, being an Atmel app note, it needs some correcting. At least the original version did.

Whereas I love the Arduino and its bootloader, the Xplained bootloader seems a pain in the *rse.

If you are using an Xmega, I would advise buying a Dragon or JTAGICE-3.

David.

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

No, I never got the m1284 to work. It comes up in lsusb EXACTLY like the x128a1:

Bus 002 Device 023: ID 03eb:2122 Atmel Corp. XMEGA-A1 Explained evaluation kit

Missed the bit about the 1927.zip file...thanks for that. I hadn't downloaded it since the plan is to use the boards as quick-and-dirty heater-controllers for data-collection to a PC.

The JTAGICEMKII does fine for programming the part, and I have plenty of running Xmega code so I typically just debug with printf.

BUT, I wouldn't mind getting the USB/USART gateway to work as a RS232 pass-through like the AT32UC3C-EK one does. That way I wouldn't need to buy six TTL-to-USB/RS232 converters for the customer. (which is what I'm using at the moment)
Maybe I need a different DFU for the UC3B?

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

The USART gateway should work just fine.

Obviously the Xmega bootloader or Mega bootloader must be intact if you want to load programs this way.

Since you have a JTAGICE-mkII, you can restore any bootloaders. And you have the usual Atmel feature 'debug and destroy any bootloader'.

Mind you, the Xmega keeps its bootloader in a separate memory space. So you should not need to destroy and debug.

I presume that there must be many Xplained owners.
Of course most people will use Windoze and consequently be able to debug painlessly via JTAG or PDI.

I keep asking, but never seem to get a convincing reply. Is there any "fully functional" Studio equivalent for Linux ? i.e. GUI debugger, competent Simulator, ...

Rowley CrossWorks runs pretty well on Linux. Unfortunately their Xmega support in the C compiler is pants. But their debug environment for Mega and Tiny is far better than Studio 4 and similar to Studio 6.

Does anyone have an Eclipse or CodeBlocks that runs out of the box for AVRs in Linux?

Yes, another reason for getting Flip or otherwise to run on Linux: restoring AT32UC3 gateway after b*ggering.

David.

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

Quote:

The USART gateway should work just fine.

Well, it does not work, and I have tried it on multiple Linux distributions.

HOWEVER!!! I just noticed THIS by Dean where he says this is a known problem:
https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=125613&highlight=xplained+ttyacm0

And of course I can't have AS6 on Linux, so I sure could use the HEX file if someone could provide it. I have also noticed a couple of older threads where people had the same issue which went unresolved...e.g.https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=107111&start=0&postdays=0&postorder=asc&highlight=

Perhaps this HEX file could be made available somewhere--perhaps in a sticky? I burned a LOT of time on this issue and it would be really great to get that USART gateway to work!

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

OK, for those who want to use an Xplained board on Linux, here's the latest I have found on this issue.
Note, there are several things which still don't work properly, but I've made considerable progress. Hope this helps.

The Xplained boards with the AT32UC3B1256 interface processor DO NOT WORK on Linux out-of-the-box.

Although they enumerate to /dev/ttyACM0 they won't communicate and terminal programs hang or are otherwise unresponsive.

You MIGHT be able to type characters and get the LED to flash and the J4 RX pin to wiggle, but your USART code won't be able to respond all the way back to the PC.

----- TO FIX THIS -----
You must rebuild the application on the UC3B processor from an example app in the ASF.

In linux, it can be found in the Atmel Software Framework 3.5.1 (asf-standalone-archive-3.5.1.62.zip)

    asf-3.5.1/common/services/usb/class/cdc/device/example/at32uc3b0256_board_controller/gcc
In AVR Studio 6 the example project is:
    "USB Device CDC Example - Board Controller"

Using the default settings from this project will cause the board to have a USB-PID of 0x2310.
(the 2310 PID is for an EVK11xx evaluation board...not an XMEGA-Xplained which has PID 2122) or whatever yours may be.

If like me, you want the correct PID for your board, you need to change the file:

    asf-3.5.1/common/services/usb/class/cdc/device/example/conf_usb.h
Locate these lines:

#if BOARD == UC3B_BOARD_CONTROLLER
#define   USB_DEVICE_PRODUCT_ID            USB_PID_ATMEL_XPLAINED
#else
# define  USB_DEVICE_PRODUCT_ID            USB_PID_ATMEL_ASF_CDC
#endif

and change:
# define  USB_DEVICE_PRODUCT_ID        USB_PID_ATMEL_UC3_CDC_DEBUG
to:
#define   USB_DEVICE_PRODUCT_ID        USB_PID_ATMEL_XPLAINED

Note: if you have a different board then select from:

    asf-3.5.1/common/services/usb/usb_atmel.h
Then build the project and use dfu-programmer or Flip to reprogram the UC3B processor's application.

In Linux I used dfu-programmer:

    1. Jumper the reset line to the at32uc3b1256 and boot into the DFU-bootloader. (use the provided BC BOOTLOADER holes for this, they're labeled on the back)

    2. Erase the application code by runnning the command:
    dfu-programmer at32uc3b1256 erase
    Note this does not erase the UC3B's bootloader.

    3. Program the new application code by runnning the command:
    dfu-programmer at32uc3b1256 flash --suppress-bootloader-mem example-code-built-and-changed-to-2122.hex

    4. Reset the UC3B's bootloader to run its application at startup by running the command:
    dfu-programmer at32uc3b1256 start

Now the communication is BI-directional and I am successfully communicating to my Xmega through USARTC0 and /dev/ttyACM0.

On startup, the Linux driver may not work right depending on your terminal program. (I like miniterm.py and I wrote a python GUI too, and both have this issue. Switching baud rates and back again fixes it. (Kermit seems to work automatically. Don't know about minicom)

miniterm.py /dev/ttyACM0 57600
Ctrl-] to quit, then run:
miniterm.py /dev/ttyACM0 115200

Then it will work properly. Not long ago there was a bug in the FTDI Linux driver which exhibited the same problem. Not sure if this is related.

But as for programming through the UART-to-USB gateway using the Xmega bootloader and batchisp, I have yet to get it to work.

I did get batchisp to see my device by using a symbolic link since batchisp is too stupid to understand /dev/ttyACM0 is a port...

sudo ln -sf /dev/ttyACM0 /dev/ttyS0

In addition, Flip/batchisp are an old version on Linux and do not have xml file for these processors. LOTS of headaches to get these to even a small level of operation. I have yet to be successful with those.

Instead I program my target processor through the JTAG port using an STK600. I also tested PDI programming using the STK600 and it worked too after changing the Xmega's JTAGEN bit in fuse4, but I still program using JTAG for now.

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

One thing I happened to note while studying this mess:

the source code in the "USB Device CDC Example - Board Controller" seems to be default configured for a baud rate of 57600 as I understand it, look further down in that same file (conf_usb.h). That might explain some of the communication problems and also the need to switch baud rates back and forth.

/Manni

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

kmceng wrote:
Perhaps this HEX file could be made available somewhere-

:)
Any chance you could post that hex file kmceng (if you can still find it three years later)?
I currently don't have access to AVRStudio and have wasted many hours trying to build from ASF on Linux- (time I wanted to spend on the actual xmega).

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

Here is the .hex file using the instructions above, for anyone else who may not be using AVRStudio.

Attachment(s):