Author Topic: Digispark as programer for Femtodino.  (Read 5917 times)

se5a

  • Newbie
  • *
  • Posts: 8
Digispark as programer for Femtodino.
« on: March 06, 2014, 06:20:41 pm »
trying to use a digispark to program an http://www.femtoduino.com/

I set the spark up with littlewire, that seemed to go ok. I wasn't sure weather the windows driver should then have been the littlewire or the digispark one, I tried both but had the same problem with either.

using the digispark arduinio IDE, loaded the project, set the board to Arduino UNO and the programmer to Digispark.
File->Upload using programmer.
the IDE asked me to plug in the device... ok so I connected up the femto.... nothing happened. re-plugged the spark, and got the message:

> Device is found!
connecting: 16% complete
connecting: 22% complete
connecting: 28% complete
connecting: 33% complete
> Available space for user application: 6010 bytes
> Suggested sleep time between sending pages: 8ms
> Whole page count: 94
> Erase function sleep duration: 752ms
parsing: 50% complete
> Program file is 9484 bytes too big for the bootloader!

the binary sketch size is 15,494 bytes. femto should take 32k...
any ideas what I'm doing wrong?

gogol

  • Sr. Member
  • ****
  • Posts: 398
Re: Digispark as programer for Femtodino.
« Reply #1 on: March 07, 2014, 05:47:33 am »
as long, as you are using digispark as programmer, you are uploading code to the digispark!

Once you have loaded littlewire to the digispark, the digispark works as USBtinyISP.  When you plug in a digispark-littlewire, you will see first, that your system recognizes the digispark.  That is for 5 sec. while the bootloader waits, if the digispark itself should be (re-)programmed.  After that the littlewire application starts, your system should recognize a new device, which you can see below "libusb-win32 USB devices" in the device manager, and the device is called  USBtinyISP.

You select than in Arduino USBtinyISP as programmer for uploading sketches to the connected devices. 

se5a

  • Newbie
  • *
  • Posts: 8
Re: Digispark as programer for Femtodino.
« Reply #2 on: March 07, 2014, 11:46:14 am »
ah. I may have skipped the libusb driver bit.
under device manager it's showing up under libusb-win32 Usb Devices as 'Little Wire'
not USBtinyISP.
the instructions here: http://sourceforge.net/apps/trac/libusb-win32/wiki
are damnably confusing as i'm not sure what I'm trying to achieve. not sure if I want to do the 'filter driver' bit or just the 'device driver'
I attempted the filter driver instructions but the spark didn't show up. the whole libusb feels like they've tried to dumb things down and made it more complicated in the process.

Edit. ok figured that out.
spark now shows in device manager as USBtinySPI

however when I try to upload using programmer I get this:

Binary sketch size: 15,494 bytes (of a 32,256 byte maximum)
Running AVRDUDE...
avrdude_original: initialization failed, rc=-1
                  Double check connections and try again, or use -F to override
                  this check.



what now?


pretty sure I've got it wired up right:

Code: [Select]
digispark pins
0   1   2   5
|   |   |   |
11  12  13  rst
femto pins

and yes it is powered.
wondering if the femto is borked. not sure how I could test this.
maybe some time in the past I used Burn Bootloader? would that cause what I'm seeing?
« Last Edit: March 08, 2014, 11:48:50 am by se5a »

gogol

  • Sr. Member
  • ****
  • Posts: 398
Re: Digispark as programer for Femtodino.
« Reply #3 on: March 09, 2014, 03:12:26 am »
If femto pins 11 is MOSI,
                    12 is MISO and
                    13 is SCK
you should be OK.

MOSI goes to MOSI (not like RX to TX), as the name states:  "Master OUT, Slave IN"

I had this message for example, when I burned wrong fuses with one of my first tries. Whenever I disabled RESET or serial programming, the chip was dead.

The problem with ISP is, that you are able to set certain fuses only once. And after setting the fuse, the ISP connection is dead. I am not sure, if that is your problem, but you should always double-check fuse settings before programming small AVRs.

I wrote the following article, where I reported my experience.

However as far as I know, the femto uses an atmega328, which uses HVPP, so its not covered by my article, which covers only HVSP

« Last Edit: March 09, 2014, 03:30:34 am by gogol »

gogol

  • Sr. Member
  • ****
  • Posts: 398
Re: Digispark as programer for Femtodino.
« Reply #4 on: March 09, 2014, 03:35:10 am »
Quote
maybe some time in the past I used Burn Bootloader? would that cause what I'm seeing?

Thinking about, there is an easy way to break your fuses:

When you have selected the digispark as board, but the USBtinyISP as programmer, the connected device has reset disabled.

The digispark section in the boards.txt reflects the currenty fuse settings with reset disabled, but makes no use of them, as the micronucleus is not able to burn fuses!

« Last Edit: March 09, 2014, 01:19:50 pm by gogol »

se5a

  • Newbie
  • *
  • Posts: 8
Re: Digispark as programer for Femtodino.
« Reply #5 on: March 09, 2014, 10:42:56 pm »
I ended up ripping my mega2560 out of another project (something I was trying to avoid) and tried with that, ran into the same problem, quadruple checked my wires... and realised I'd gotten reset and clock round the wrong way (this may have been the problem when trying with the digispark).
messed around with avrdude at the commandline from there just to see what I could figure out and attempt to get a better understanding of what the IDE was doing but I was getting Device signature = 0x000000, and something about not being in sync. I forget the exact message now.
I think I'll just order another femtoduino.

I don't think it happened when I was attempting to program it this time around. the board was never set as digispark in the arduino IDE/avrdude - it was just the windows driver.
I don't think I managed to write to it at all. half the problem is it's a project I've not touch for over a year and it's been sitting at the back of my desk gathering dust. I'm wondering if I've killed the chip previously without realising. I don't remember at all back then. (I *thought* I'd successfully programmed it and had it working, but it was not working at all when I attempted to start working on this project once again, hence the attempt to reprogram it)

I did read that tutorial, but found it a little hard teasing out what was relevant for my case and what was not. though now I've done it I've got a bit better of an idea.
« Last Edit: March 09, 2014, 10:54:24 pm by se5a »