Does SPI serial programming "timeout"?

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

Hi all,

I've been struggling the last few days with writing my own ISP tool to program an AVR over SPI. The tool is running on an ARM host processor and I am using a builtin SPI interface plus a GPIO to control the AVR reset.

I can get the AVR in to programming mode, read the signature bytes, read and program the fuses, and erase just fine. My trouble is with programming and reading back the flash. It seems that if there is to much delay between programming pages then everything starts to fail. I can completely fail to write a single byte if I wait a second before programming each page.

On the other hand, I did manage to program the part by pulsing the reset and entering programming mode for every single page I am trying to write. This is not a good solution.

Has anybody seen this sort of behavior and is it documented in any Atmel spec? Is there a minimum serial programming speed for a given clock speed?

Any other ideas on what may be going on?

Thanks,
-kwr

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

Nevermind - I solved my problem. Simply forgot to kill some other software that talks to the AVR over the same SPI port (I'm using SPI for both programming and communication with the programmed part).

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

Hi all,

I am very interested on this way of programing an AVR : from a ARM host through SPI directly.

I don't find any documentation on it, except here, but it is a very old message.

Does anybody can point me to some similar works ?

Thanks a lot

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

There are many STK500v1 or STK500v2 protocol programs in the public domain.

Think about it. You are simply receiving commands via the RS232 / USB and issuing the relevant SPI sequences.

All micros nowadays have an UART and a SPI interface. Even if they don't, it is simple to bit-bang either interface.

I have a STK500v2 working on a PIC. I suppose that I could port it to ARM in about an hour, but have no desire to do so. Some ARMs have 5V tolerant GPIO. They are exceedingly cagey about how tolerant the non-GPIO peripherals are.

So yes, you can turn an MBED into a free STK500 protocol ISP programmer. But your AVR targets would need to run at 3.3V

Note that there are other protocols available.
Many bootloader writers like to use non-standard protocols.

David.

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

Hi David,

thanks for your quick answer.

The AVR I use is the ATmega8L in 3,3V, and the ARM host is an OMAP3530 (overo) with 1,8V IO. I adapt the signal trough translators TXS0102, so it should not be a matter of voltage.

Thanks to pointing me the STK500v1 or v2 protocol program in public domain, this should be what I look for.
I am kind of new in the AVR world and the number of programmer make me lost a little bit...

It should be possible to adapt the protocol to a linux driver like described here : http://www.jumpnowtek.com/index....
But I cannot think nobody have done it yet. It must be somewhere, so instead of spending time coding and of course debugging, I hope to find some equivalent work somewhere, at least from another linux host... And AVRFreaks seems to be THE meeting point !!!

So I go to look for STK500 protocol program.

Thanks

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

If you just want one firmware burned into one mega8 chip, say where you are in the world.

Someone in your town / country may do it for you.

David.

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

No it is really part of my project to have the OMAP able to download the firmware on the AVR when there is an update...