Any alternative to BLIPS pc software?

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

I'm having some trouble with the BLIPS (bootloader) PC software frequently freezing and forcing me to reboot to free up the COM port. Anyone know of an alternative windows software that supports the AVR109 self-programming protocol?

I have tried it with avrdude but I get an error, The bootloader firmware seems to be otherwise working ok.

$ avrdude -p m88 -c avr109 -P COM6 -b 38400 -F -U flash:r:-:i

Connecting to programmer: .
Found programmer: Id = "Mega88 "; type = S
    Software Version = 1.2; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=64 bytes.

Programmer supports the following devices:
    Device code: 0x77

avrdude.exe: AVR device initialized and ready to accept instructions

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

avrdude.exe: Device signature = 0x1e930a
avrdude.exe: error: programmer did not respond to command: set addr

My setup:

ATmega88 with 16Mhz crystal
BLIPS v4 bootloader @ 38400 baud
Windows XP SP2
Prolific virtual COM port

Any suggestions?

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

Try EasyBootAvr.

I noticed BLIPS PC software takes full processor. I think it have while loops waiting for the AVR to respond. EasyBootAVR is based on timers. It takes only few procents from your machine to work even if waiting.
Stevech can give you more details.

George.

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

Thank you for your reply angelu I will certainly keep your suggestion in mind although I would really prefer to stick with the AVR109 protocol if possible.
My target device is currently situated inside a D25 hood with no space for ISP pins. The MCU is socketed so I can burn a different bootloader if necessary, it's just a real PITA to get the darned thing opened.

I should make it clear that the BLIPS software does work for the most part, it's just that these freeze-ups are not making for happy developing :(

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

I have never had any problems with Blips , but with Vista & Windows 7 & USB , who knows?

I have recently started to use Osama's SparkLoader
http://www.softpedia.com/get/PORTABLE-SOFTWARE/Programming/Spark-Loader.shtml
It is small & works very well!

Charles Darwin, Lord Kelvin & Murphy are always lurking about!
Lee -.-
Riddle me this...How did the serpent move around before the fall?

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

maximax wrote:
I'm having some trouble with the BLIPS (bootloader) PC software frequently freezing and forcing me to reboot to free up the COM port. Anyone know of an alternative windows software that supports the AVR109 self-programming protocol?

Any suggestions?


I'd be happy to help diagnose this - with more specifics. BLIPS is freeware and has been out there for years and the above is the first I've heard of such a problem. Perhaps it's related to your "Prolific virtual COM port" - which I assume is a USB to serial adapter with a windows driver. Many people, me included, choose either FTDI based USB/serial adapters or Edgeport. Both have flawless windows drivers.

But send more specifics; perhaps others have seen this?

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

stevech wrote:
Perhaps it's related to your "Prolific virtual COM port" - which I assume is a USB to serial adapter with a windows driver.

It is listed under Device Manager as: Prolific USB-to-Serial Comm Port (COM6) The driver supplied is PL-2303
I think the problem is almost certainly linked to the COM port since in addition to the freezing-up another slightly less annoying problem is that I have to constantly re-plug the usb adapter to get it to respond again after any period of inactivity.

My main gripe is that when the BLIPS program freezes I cannot even kill the process with the Task Manager. As a consequence I cannot run the program again or use the COM port unless I reboot my system.
The problem usually occurs first time I try to read the chip ID after running the BLIPS program it reports:

Opened COM6 38400,n,8,1
Using Atmel Application Note 109 Programming Protocol
sending[delay][purge input]

Then BLIPS.exe stops responding, when I end the process under Task Manager the window dissapears but the BLIPS.exe process reamins in list of running processes. If I try to run BLIPS again nothing happens. Removing the usb adapter does not make any difference.

Not sure what other info I can provide since I am not getting any specific error messages but let me know if I missed anything. I think perhaps I will look for a FTDI based adapter and this problem might just go away.

Thank you for your help.

EDIT: As I was writing this I made a discovery. After re-creating the problem It seems that if I leave it alone for an undetermined period of time the process does eventually dissapear from the running processes list and the app can be restarted, well thats good to know atleast.

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

I've had a lot of problems with PL2303 drivers in the past - on XP it used to cause BSOD's - at least that doesn't happen in Vista (about the only good thing I can think of to say about it)

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

Regarding the original problem with avrdude compatibility, I've just recently run into this myself.

I was in the situation where the bootloader would work exactly once on a freshly ISP programmed chip (i.e. empty except for the bootloader), but as soon as I loaded some application code it would fail to re-program.

The problem appears to be due to the commented out lines in section L17x6.

L17x6:
;;;		cpi	R16,'E'				; 'E' for block mode EEPROM data			; 
;;;		rjmp	cmdUnknown			; NOT IMPLEMENTED - will wind up at cmdUnknown

avrdude always seems to send a block mode EEPROM read command. Without this section, the trailing 'E' character is incorrectly interpreted as an exit command, and execution jumps to the beginning of flash. If the chip is otherwise empty I presume it just NOPs through the FF instructions until it reaches the bootloader again, which is why it works successfully the first time.