Pages: [1] 2   Go Down
Author Topic: ArduinoISP on Arduino DUE  (Read 3903 times)
0 Members and 1 Guest are viewing this topic.
Offline Offline
Newbie
*
Karma: 0
Posts: 24
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hi, I'm trying to figure out whether I can use my ArduinoDUE board as an ISP programmer. So I first tried to upload ArduinoISP sketch using Arduino 1.5.2 IDE version, but I get the following error concerning SPI registers:

Code:
ArduinoISP.ino: In function 'void spi_init()':
ArduinoISP:159: error: 'SPCR' was not declared in this scope
ArduinoISP:160: error: 'SPSR' was not declared in this scope
ArduinoISP:161: error: 'SPDR' was not declared in this scope
ArduinoISP.ino: In function 'void spi_wait()':
ArduinoISP:167: error: 'SPSR' was not declared in this scope
ArduinoISP:167: error: 'SPIF' was not declared in this scope
ArduinoISP.ino: In function 'uint8_t spi_send(uint8_t)':
ArduinoISP:172: error: 'SPDR' was not declared in this scope

The SPI Reference says

Quote
Extended SPI library usage with the Due
On the Arduino Due, the SAM3X has advanced SPI capabilities. It is possible to use these extended methods, or the AVR-based ones.

so I thought it could work using basic AVR methods.
Does anybody know whether this is due to a lack of AVR->SAM3X code translation, as well as for interrupt.h and we just have to wait? Thanx for your help
Logged

Offline Offline
Full Member
***
Karma: 9
Posts: 116
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

It can be done, but if you have an alternative (uno, leo...) that is more practical.

First of all, the due is not 5V tolerant. I solved this the simplest way by powering the target AVR with 3V3. This worked for me for ISP'ing my Leonardo and a Duemilanove. It failed for an attiny85...

The sample ArduinoISP in the ide is rather old, it should be updated. So get ArduinoISP here: https://github.com/rsbohn/ArduinoISP. That version is updated to use the SPI library instead of implementing the spi stuff inside the sketch using the AVR specific registers.

I used an SPI clock divider of 255 (the slowest one), the constant in the ArduinoISP sketch is not defined for the Due.

Then there is the autoreset problem. The due's native port autoresets when you open it, this is a classical problem that will cause "burning a bootloader via the ide" to fail. A good alternative is to replace all occurences of Serial into SerialUSB and thus use the native usb port instead of the programming port. This port does not autoreset when opening it.

Finally, I observed a problem when stopping and restarting SPI. But as said, I managed to upload a bootloader into a Leonardo and a Duemilanove.

I am preparing writeups on how to disable autoreset for the programming port and on running ArduinoISP on the due but I am a bit behind with things...
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 24
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Thank you, it worked out! I mean new ArduinoISP sketch was flashed correctly, next I would like to use it to program an ATtiny uC.
So I should replace every instance of Serial with SerialUSB and then use the programming port to upload the sketch ArduinoISP, after that connect the DUE board to the native port and flash the sketch on the external uC?
Do you think I can use the onboard SPI 6 pins?
Logged

Offline Offline
Full Member
***
Karma: 9
Posts: 116
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
So I should replace every instance of Serial with SerialUSB and then use the programming port to upload the sketch ArduinoISP, after that connect the DUE board to the native port and flash the sketch on the external uC?
Yes
Quote
Do you think I can use the onboard SPI 6 pins?
Yes that is the one to use but be carefull that the target uc does not drive the SPI pins at 5V or the due is damaged. As said before I powered the target at 3V3 to ensure this. (In particular, I left the VCC pin on the Due's SPI headers un connected: it is 5V!)

As said I can't program nor run my attiny at 3V3, allthough according to the datasheet it should work (BOD is disabled). Maybe my attiny is broken, maybe I am missing something.  (If somebody has ideas, that would be great).







Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 1
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

So goan, I'm still confused. I was getting the same error as you. What did you do to solve your problem? I'm pretty new to programming, but from the 'getting started with arduino due' page, it seems I should be using the programming port. Any help from anyone would be greatly appreciated.
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 24
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hi purple_lily.
I followed PeterVH's instructions in order to download ArduinoISP updated version. Then you have to back up your older version in arduino/examples folder and put the new one inside. After that I tried to upload it to my ArduinoDUE and everything worked fine! In the meanwhile I've been a little busy  and I was also waiting for some attiny from farnell. I think I'll try to make it work in the next days.
Logged

Offline Offline
Full Member
***
Karma: 9
Posts: 116
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

I have picked up the ArduinoISP on Due experiment.
Quote
I observed a problem when stopping and restarting SPI.
A fix is proposed here:
http://forum.arduino.cc/index.php?topic=165497.0
Quote
I can't program nor run my attiny at 3V3, allthough according to the datasheet it should work
Not being able to run it at 3V3 was a silly wiring error on my side.

However I still can't program the attiny85 from my Due. I figured this could be because of the 3V3 or the SPI speed or a combination of both.

So for comparison, I hooked up the attiny to an atmega328p@16MHz that I powered at 3V3 and that runs ArduinoISP. This worked with the standard  SPI_CLOCK_DIV128. Then I tried higher SPI speeds. SPI_CLOCK_DIV64 still works, but SPI_CLOCK_DIV32 does not! So 4MHz/32 == 125kHZ seems too fast! On the Due I use clock divider 255 resulting in 84MHz/255 == 329kHz. So speed seems to be the problem: the Due is too fast.

To compare this experimental result to the spec: the tiny's lfuse is 0x62 which means 8Mhz internal with a clock divider of 8 => 1MHz cpu clock. The spec says the duration of an SPI SCK  must be 2 cpu cycles high and 2 cycles low => max SPI speed is 250 KHz. If I interpret the data sheet well, my experiment should have worked. My experimentation board setup could be responsible for this though this stuff works for an atmega328p@16MHz as target... anyway 250kHz is still slower than the Due's slowest SPI speed.

Has anybody similar experiences with the tiny's max ISP speed? (I could have mis interpreted the data sheet).

I see no way to configure the Due for a slower SPI.

It seems a bit over the top but I am going to try to use software spi for this...
Logged

Wahiawa, Hawaii
Offline Offline
God Member
*****
Karma: 29
Posts: 600
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Why don't you just program the t85 with an external 16MHz crystal, then later change the fuse settings to internal clock settings.

Logged

Global Moderator
Dallas
Offline Offline
Shannon Member
*****
Karma: 208
Posts: 12940
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Has anybody similar experiences with the tiny's max ISP speed?

I do.  There is some variance (I assume because of different fabs / batches).  With some processors I have had success programming over the recommend SPI bitrate but never by more than double.  I have never had problems using 125 KHz SCK for targets running at 1 MHz and 2 M SCK for targets running at 8 MHz.

Quote
(I could have mis interpreted the data sheet).

My interpretation is not the same.  This is from the t85 datasheet...

Quote
Low: > 2 CPU clock cycles for fck < 12 MHz, 3 CPU clock cycles for fck >= 12 MHz
High: > 2 CPU clock cycles for fck < 12 MHz, 3 CPU clock cycles for fck >= 12 MHz

That is greater than 2 CPU clock cycles for CPU clock speeds less than 12 MHz.

Quote
I see no way to configure the Due for a slower SPI.

Use bit-banging.  Nick Gammon has an implementation on his site that can probably be dropped-in.
Logged

Anchorage, AK
Offline Offline
Edison Member
*
Karma: 42
Posts: 1176
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I seem to remember reading something in the datasheet about whether the ISP polls for completion of a flash operation, or just waits until "probably" long enough before sending the next command.  If it turns out not to be a sampling issue on the SPI pins, you might check if the flash ops have enough time to complete before the next command is sent.  Just an idea.
Logged

Global Moderator
Dallas
Offline Offline
Shannon Member
*****
Karma: 208
Posts: 12940
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Just an idea.

A good idea.


Quote
I seem to remember reading something in the datasheet about whether the ISP polls for completion of a flash operation, or just waits until "probably" long enough before sending the next command.

Most (all?) AVR processors in the Arduino world support polling.  It is much more effective than waiting.  But, the ArduinoISP sketch does not poll (at least it didn't that last time I checked).

I believe the ArduinoISP sketch waits approximately twice the time Atmel recommends which is about twice again from the time programming actually takes.  But, as SirNickity stated, it is worth checking the delay to ensure it really is long enough.
Logged

Offline Offline
Full Member
***
Karma: 9
Posts: 116
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

I did not get at flash related commands yet. I first wanted to see whether the spi part of the story worked, so I started with something simple: a read signature command. And that fails already.

Nevertheless it is an idea I want to read about, maybe it is an opportunity to improve ArduinoISP...

Right now I am giving bit banged SPI a try.



Logged

Valencia, Spain
Offline Offline
Faraday Member
**
Karma: 146
Posts: 5535
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset


Reading the datasheet? Radical, dude!

Logged

No, I don't answer questions sent in private messages (but I do accept thank-you notes...)

Offline Offline
Full Member
***
Karma: 9
Posts: 116
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Great, I have ArduinoISP working with Nick Gammon's bit banging SPI (on AVR).

Will try with the Due tomorrow.

This looked like a silly idea, but doing so, I already bumped into what looks a long standing bug in ArduinoISP (it is listed in ArduinoISP's google code site) : when entering programming mode, RESET must be pulled low first, then SCK pulled low and then RESET should be pulsed briefly high because this is no poweron-reset situation. Instead ArduinoISP first pulls SCK low then RESET which causes a brief (well...) short circuit if the target drives SCK high... I have never seen a problem with this on my AVR's but with the Due I want to be careful.
Logged

Global Moderator
Dallas
Offline Offline
Shannon Member
*****
Karma: 208
Posts: 12940
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

I have never seen a problem with this on my AVR's but with the Due I want to be careful.

It's only an issue if the target is driving SCK at the moment the programmer does its thing.  Which would be rarely.  But, it is a bug.

Have you considered working with TinyISP instead of ArduinoISP?
https://github.com/Coding-Badly/TinyISP

Nick has a good example of RESET handling...
https://github.com/nickgammon/arduino_sketches/blob/master/Atmega_Board_Programmer/Atmega_Board_Programmer.ino#L523
Logged

Pages: [1] 2   Go Up
Jump to: