Get Your Open Source XPLAIN/XMEGA Programmer Here!

Go To Last Post
124 posts / 0 new

Pages

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

Quote:

Is it possible that AVRStudio do this to Non-atmel programmers after a few chip programming?

Studio 4, or Studio 5? If the former, I've been using Tom's programmer loaded with my code for quite a while under Studio 4, with no issues at all.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

I guess this is the best place to post the issue, other than support group for LUFA.

I have an issue with Xplain Bridge on windows 7 32 Bit(Enterprise).

when i try to load driver file(.inf) it just doesnt works.

i made Xplain work as MKII so i think is not really my hardware.

anyone have any suggestions to solve this?

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

Are you using the .INF file located on my website? If so, are you running in Serial Bridge mode, or AVRISP-MKII mode?

If the former, give Windows the INF from my site. If the latter, you need to give Windows the location of the Atmel AVRISP-MKII drivers, which ship along with AVRStudio.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

does LUFA work for new Xplained board(shiped with at32uc3b1256) now?

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

The LUFA core is ported, but that project is not. I've been busy with a few other things lately, but given the large amount of interest perhaps I should re-prioritize.

The big changes would be writing an appropriate UART and SPI driver for the AVR32s, and fixing up the endianness issues in the demo.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

abcminiuser wrote:
The LUFA core is ported, but that project is not. I've been busy with a few other things lately, but given the large amount of interest perhaps I should re-prioritize.

The big changes would be writing an appropriate UART and SPI driver for the AVR32s, and fixing up the endianness issues in the demo.

- Dean :twisted:

nice guy!!

i'm new to avr32, in my xplainED board, i can switch AVR32 into bootloader mode via the jumper. And I can use dfu-programmer access the AVR32 chip, so I think I can re-program it. The question is, if I upload a hello world program into, will the DFU bootloader(on AVR32) be broken?

If the operation is safe, I also want join your LUFA proj to let xplained broad works well under Linux.

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

Quote:

The question is, if I upload a hello world program into, will the DFU bootloader(on AVR32) be broken?

The serial bootloader in the XPLAINED boards is why I haven't put in the effort before now to port the bridge firmware in LUFA; you can already do both debugging and programming through the existing board controller.

Yes, you can reprogram the AVR32 through the bootloader without damaging the bootloader; that's the point. Reprogramming with an external programmer such as a Dragon or JTAG will erase the bootloader however.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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


you can already do both debugging and programming through the existing board controller.

No, i can't do it under LinuX, even i can't import the device into my virtualbox(which m$ windows there)

the linux kernel did create a file /dev/ttyACM0, but any access will lock system for several seconds(permission is correct). And then check the kernel log, you'll find some usb low-level timeout event.
So I think the main firmware on AVR32 has some bug, let the usb device not a standard one.

you can follow this link:
https://www.avrfreaks.net/index.p...

====
if re-programming AVR32 via bootloader is safe, i'll try some testing code

Thank you!

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

Quote:

the linux kernel did create a file /dev/ttyACM0, but any access will lock system for several seconds(permission is correct). And then check the kernel log, you'll find some usb low-level timeout event.
So I think the main firmware on AVR32 has some bug, let the usb device not a standard one.

Try opening the port with a standard serial terminal program such as PuTTY - that should set the baud rate (while directly cat'ing to /dev/ttyACM0 won't). The device firmware may time out unless the port settings are indicated beforehand.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

abcminiuser wrote:
Quote:

the linux kernel did create a file /dev/ttyACM0, but any access will lock system for several seconds(permission is correct). And then check the kernel log, you'll find some usb low-level timeout event.
So I think the main firmware on AVR32 has some bug, let the usb device not a standard one.

Try opening the port with a standard serial terminal program such as PuTTY - that should set the baud rate (while directly cat'ing to /dev/ttyACM0 won't). The device firmware may time out unless the port settings are indicated beforehand.

- Dean :twisted:

I used a lots of tools, like cutecom/ minicom or access the /dev/ttyACM0 by python serial port, the result is the same.

you tried the Xpalined under Linux?

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

Hi all, Dean, does the AT32UC3B1256 works now ? I also have an xplain with that chip and I want to start with programing the 128A1.
If I am not wrong, then I might have rev #9 board.

on your page there I can only see at90USB1287 support.

Pls redirect me to the right direction ... or so. ;)

thanks
D

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

No, unfortunately I never did finish the port, although I don't think it would take more than a week's effort with the latest release. That said, I don't think the programming pins are routed to the UC3B on those boards, so porting might not be much use. If I remember correctly, the XPLAIN boards with the UC3B board controller all have a serial bootloader loaded in from the factory that you can use with FLIP from the command line.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Hi Dean, Thanks for your reply.

My problem with that board is, that I damaged somehow the BL from the BC so I cannot use the UC3B anymore without reprogramming. But it is still showing as DFU device in windows (any only DFU not the CDC or similar) so my last hope was to receive from Atmel the original BL for the BC or an alternate LUFA ;)

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

You can grab the original board controller firmware for the boards in AS6: start a new example project, and search for "board controller".

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

really, cool !!!
that sounds interessting. what is the exact precedure to get the BL on the BC without destroying it completely ?
I only can use batchisp.
do you know the exact comment for batchisp ?
batchisp -device at32uc3b1256 -hardware usb -operation
??

Thank you so much dean ;)

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

You can't break the chip with FLIP (or BATCHISP) unless you load in a bad program that exploits the hardware to cause physical damage, so don't stress.

batchisp -hardware usb -device at32uc3b1256 -operation erase f loadbuffer BoardControllerFirmware.hex program

batchisp -hardware usb -device at32uc3b1256 -operation start reset 0

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Quote:

unless you load in a bad program that exploits the hardware to cause physical damage

So avoid using the HCF opcode!

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

gentleman, all working now, thanks for your great support !!! what I did so far:

1. create new "USB Device CDC Example - Board Controller"
2. compile
3. batchisp -hardware usb -device at32uc3b1256 -operation erase f loadbuffer DEVICE_EXAMPLE2.hex program

batchisp -hardware usb -device at32uc3b1256 -operation start reset 0

now we should have back the CDC as I have :)

now I am open for the NEXT problems :)
(I am trying to get the 24 PWM's working... )

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

There is a strange problem with my LUFA based mkii. When connected to usb connectors in the back side of PC, everything is ok. But by connecting the usb cable to the connectors in the front side of PC, the at90usb162 warms up very quickly! I have tested this case with more than one programmer and 2 PCs.
Another question: there are 3 LEDs connected to PD5,PD6 and PD7. What are the exact function of these LEDs?

Ozhan KD
Knowledge is POWER

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

Well that's strange, do you have the exact schematic for your programmer? I suppose there could be a voltage difference in the bus between the back and front ports, which might upset the internal regulator in the USB AVR.

EDIT: The LED functionality depends on what modifications were made to my code. Stock there's a bicolor LED to indicate activity, and a red LED to indicate if the target is being powered from the programmer.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

By putting a 5.6v zener diode and 10uF capacitor on 5v line, the problem disappeared.
And about LEDs: Single (red) led which indicates power connection, blinks during programming. So I omitted the bicolor led and it seems the single led is sufficient for programming indication.

Ozhan KD
Knowledge is POWER

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

Hi.  I'm new to the forum -- this LOOKS like the most correct forum for my question, since it starts out with the announcement of the firmware in question.

 

I loaded the Xplain Bridge firmware to my Xplain rev4. (Thank you, by the way... this thing has been collecting dust since 2010 once I figured out that I'd need to go buy something else to program it.)

 

With the Atmel Studio version firmware, almost everything works great from Atmel Studio.  Signature read worked.  I could not read out the original demo program/EEPROM (always errored out), [I wanted to save it before I overwrote it with my programs], but i was able to load a LED blinky code of my own and have it work.

 

I switched over to avrdude/CrossPackAVR under Mac OS X and it doesn't seem to be working quite right.  I changed the bridge firmware to the avrdude version (though on reading the thread history, perhaps this was only needed for avrdude under Windows):

 

First, with AVRdude 6.0.1 which came with CrossPackAVR, I can't even read the signature:

 

AVR $ avrdude -p x128a1u -C /usr/local/CrossPack-AVR/etc/avrdude.conf -c avrispmkII -P usb -U signature:r:test.hex:h
avrdude: stk500v2_recv_mk2: error in USB receive
avrdude: usbdev_send(): wrote -107 out of 1 bytes, err = usb_bulk_write: An error occured during write (see messages above)
avrdude: stk500_send_mk2(): failed to send command to serial port

 

 

I downloaded and compiled AVRdude 6.3 from source.  At least the signature read seems to work:

avrdude-6.3 -p x128a1u -C /usr/local/CrossPack-AVR/etc/avrdude.conf -c avrispmkII -P usb -U signature:r:test.hex:h

 

avrdude-6.3: AVR device initialized and ready to accept instructions

 

Reading | ################################################## | 100% 0.00s

 

avrdude-6.3: Device signature = 0x1e974c (probably x128a1u)

avrdude-6.3: NOTE: Programmer supports page erase for Xmega devices.

             Each page will be erased before programming it, but no chip erase is performed.

             To disable page erases, specify the -D option; for a chip-erase, use the -e option.

avrdude-6.3: reading signature memory:

 

Reading | ################################################## | 100% 0.00s

 

avrdude-6.3: writing output file "test.hex"

 

avrdude-6.3 done.  Thank you.

 

However, if I try to read the application flash (my blinky program is still on there):

 

avrdude-6.3 -p x128a1 -C /usr/local/CrossPack-AVR/etc/avrdude.conf -c avrispmkII -P usb -U application:r:test.hex:h

 

avrdude-6.3: AVR device initialized and ready to accept instructions

 

Reading | ################################################## | 100% 0.00s

 

avrdude-6.3: Device signature = 0x1e974c (probably x128a1u)

avrdude-6.3: NOTE: Programmer supports page erase for Xmega devices.

             Each page will be erased before programming it, but no chip erase is performed.

             To disable page erases, specify the -D option; for a chip-erase, use the -e option.

avrdude-6.3: reading application memory:

 

Reading | #####                                              | 9% 0.17savrdude-6.3: stk500v2_command(): error in CMD_XPROG: Timeout

avrdude-6.3: stk600_xprog_paged_load(): XPRG_CMD_READ_MEM failed

avrdude-6.3: stk500v2_recv_mk2: error in USB receive

avrdude-6.3: usbdev_send(): wrote -107 out of 1 bytes, err = usb_bulk_write: An error occured during write (see messages above)

avrdude-6.3: stk500_send_mk2(): failed to send command to serial port

avrdude-6.3: stk500v2_recv_mk2: error in USB receive

avrdude-6.3: usbdev_send(): wrote -107 out of 1 bytes, err = usb_bulk_write: An error occured during write (see messages above)

avrdude-6.3: stk500_send_mk2(): failed to send command to serial port

avrdude-6.3: stk500v2_recv_mk2: error in USB receive

 

...and so on for dozens of times.

 

Desperate, I installed macports and got avrdude 6.3 from there, with basically the same results.

Any other clues as to what may be going on?

 

Thank you to anyone who can help.

 

CT

 

 

Bear with me.

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

Ok, I'm a fool.

 

Some time during my going back and forth between AVR Studio and AVRdude, I had left my XPLAIN with the AVR Studio Bridge firmware, so that was the problem after I've upgraded to avrdude 6.3

I think the end result is:

AVRdude6.1 (CrossPackAVR) Doesn't work
AVRdude6.3 (compiled with some old libusb from Fink) Doesn't work
AVRdude6.3 (macports install) Works
AVRdude6.3 (compiled with libusb 1.0.22 from macports) Works
AVRStudio 4 Works (with AS bridge)

 

So false alarm.  

Happy hacking.

Bear with me.

Last Edited: Wed. Jun 6, 2018 - 07:39 AM

Pages