On 2011-03-25, Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:
> In comp.arch.embedded,
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>> On 2011-03-25, Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:
>>>
>>> Atmel SAM7S can be programmed through USB. Needs a special programming
>>> application that can be downloaded from Atmel.
>>
>> Assuming you are talking about SAM-BA, this requires jumpers setting on
>> the board to force the SAM-BA code to be copied into the first couple
>> of flash sectors.
>>
>> According to a comment in a Atmel hosted tutorial, there is a limit on
>> the number of times the SAM-BA code can be copied (IIRC, 100 times was
>> mentioned).
>
> Yes, once the device is programmed, you need te restore the bootloader
> before you can program it again. For this you need to set the TST pin
> on power up. We do this via an extra pin on our programming connector
> on one product, via a jumper and a standard USB connector on another
> product.
>
> The datasheet claims 10000 write cycles. With the need to first write
> the boot loader, that would imply 5000 programming cycles. More than
> enough for most applications. I have never run into a programming
> problem, not even on a test board.
>
I have now looked further into this.
Since I was unsure about the accuracy of what was said in the Atmel
tutorial, let me start by apologising to the Atmel tutorial author as he
is quite correct; there is indeed a upper limit of 100 times for which
you can be sure that the SAM-BA re-flashing process will work.
In my defence however, I should point out that the required information
to understand the issue is buried in the middle of the errata section
of the AT91SAM7S datasheet (at least on the version I am using, which is
dated Aug 2010).
The issue is not the number of times you can write to a flash sector.
As you say, and as I already knew, there is a 10000 write cycle endurance.
The issue is that after each restoration of the SAM-BA code to flash, the
flash sectors containing the SAM-BA code are locked and there is a endurance
limit of 100 cycles for setting the lock bits.
From the AT91SAM7S datasheet (doc6175):
|40.6.4 Non Volatile Memory Bits (NVM Bits)
|
|40.6.4.1 NVM Bits: Write/Erase Cycles Number
|
|The maximum number of write/erase cycles for Non Volatile Memory bits is 100.
|This includes Lock Bits (LOCKx), General Purpose NVM bits (GPNVMx) and the
|Security Bit.
|
|This maximum number of write/erase cycles is not applicable to 256 KB Flash
|memory, it remains at 10K for the Flash memory.
|
|Problem Fix/Workaround
|None.
Depending on how you read the datasheet, clearing the lock bit and then
it been set again when SAM-BA is reloaded, may be counted as 2 operations
which means that the unlock sectors -> burn own code -> reload SAM-BA
sequence may only be guaranteed for 50 cycles.
Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Reply by Simon Clubley●March 25, 20112011-03-25
On 2011-03-25, Marc Jet <jetmarc@hotmail.com> wrote:
>> Assuming you are talking about SAM-BA, this requires jumpers setting on
>> the board to force the SAM-BA code to be copied into the first couple
>> of flash sectors.
>
> I think you got this wrong. The jumper on the dev boards is used to
> erase the flash and NVM bits.
>
> The NVM bits indicate whether or not to boot from flash. This is why
> a chip stops booting from flash and rather runs the SAM-BA code, after
> you used the jumper.
>
> Erasing many times works against the flash cycle limit, just as you
> say. But it's not a necessity of using SAM-BA. The SAM-BA code is
> not "copied" into flash ever.
>
Just to make sure we are talking about the same thing, I am talking about
the portion of the SAM-BA protocol which is implemented within the MCU
and not the host PC portion of this protocol.
I checked the AT91SAM7S datasheet (doc6175) in case I was mistaken.
I am working from the 30-Aug-10 veersion of the datasheet.
From section 8.10 of the datasheet:
|8.10 SAM-BA Boot Assistant
|
|The SAM-BA Boot Recovery restores the SAM-BA Boot in the first two sectors of
|the on-chip Flash memory. The SAM-BA Boot recovery is performed when the TST
|pin and the PA0, PA1 and PA2 pins are all tied high for 10 seconds. Then, a
|power cycle of the board is mandatory.
The SAM-BA code always boots from flash. However, since I don't use it (as I
write to flash using the JTAG interface), I unlocked the SAM-BA sectors and
replaced the copy in flash with my own code.
Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Reply by Frank Buss●March 25, 20112011-03-25
Alexander Kane wrote:
> I'm after a microcontroller with USB ISP right out of the box with
> support from the micro's regular tools.
> Important are a small footprint, though preferably not QFN or anything
> that can't be hand soldered, and that it is relatively cheap.
> This microcontroller doesn't need a whole lot of grunt, so an 8-bit or
> 16-bit would be fine.
> Assuming you are talking about SAM-BA, this requires jumpers setting on
> the board to force the SAM-BA code to be copied into the first couple
> of flash sectors.
I think you got this wrong. The jumper on the dev boards is used to
erase the flash and NVM bits.
The NVM bits indicate whether or not to boot from flash. This is why
a chip stops booting from flash and rather runs the SAM-BA code, after
you used the jumper.
Erasing many times works against the flash cycle limit, just as you
say. But it's not a necessity of using SAM-BA. The SAM-BA code is
not "copied" into flash ever.
You can just as well create a clone of the code, enhance it with a
timeout-then-run-my-main-software feature, and flash that. Then you
will be able to connect to SAM-BA as often as you want, without ever
erasing or flashing anything. Not that this would be very useful, but
it demonstrates the point.
SAM-BA protocol is documented in the datasheet, and the original
binary can be extracted using SAM-BA's memory read commands.
Best regards,
Marc
Reply by Stef●March 25, 20112011-03-25
In comp.arch.embedded,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> On 2011-03-25, Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:
>> In comp.arch.embedded,
>> Alexander Kane <ajpkane@gmail.com> wrote:
>>> I'm after a microcontroller with USB ISP right out of the box with
>>> support from the micro's regular tools.
>>> Important are a small footprint, though preferably not QFN or anything
>>> that can't be hand soldered, and that it is relatively cheap.
>>> This microcontroller doesn't need a whole lot of grunt, so an 8-bit or
>>> 16-bit would be fine.
>>> Thanks for your help.
>>
>> Atmel SAM7S can be programmed through USB. Needs a special programming
>> application that can be downloaded from Atmel.
>
> Assuming you are talking about SAM-BA, this requires jumpers setting on
> the board to force the SAM-BA code to be copied into the first couple
> of flash sectors.
>
> According to a comment in a Atmel hosted tutorial, there is a limit on
> the number of times the SAM-BA code can be copied (IIRC, 100 times was
> mentioned).
Yes, once the device is programmed, you need te restore the bootloader
before you can program it again. For this you need to set the TST pin
on power up. We do this via an extra pin on our programming connector
on one product, via a jumper and a standard USB connector on another
product.
The datasheet claims 10000 write cycles. With the need to first write
the boot loader, that would imply 5000 programming cycles. More than
enough for most applications. I have never run into a programming
problem, not even on a test board.
If you want to check out if this chip is what you want, get an
AT91SAM7S-EK.
--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)
Expense Accounts, n.:
Corporate food stamps.
Reply by Simon Clubley●March 25, 20112011-03-25
On 2011-03-25, Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> wrote:
> In comp.arch.embedded,
> Alexander Kane <ajpkane@gmail.com> wrote:
>> I'm after a microcontroller with USB ISP right out of the box with
>> support from the micro's regular tools.
>> Important are a small footprint, though preferably not QFN or anything
>> that can't be hand soldered, and that it is relatively cheap.
>> This microcontroller doesn't need a whole lot of grunt, so an 8-bit or
>> 16-bit would be fine.
>> Thanks for your help.
>
> Atmel SAM7S can be programmed through USB. Needs a special programming
> application that can be downloaded from Atmel.
Assuming you are talking about SAM-BA, this requires jumpers setting on
the board to force the SAM-BA code to be copied into the first couple
of flash sectors.
According to a comment in a Atmel hosted tutorial, there is a limit on
the number of times the SAM-BA code can be copied (IIRC, 100 times was
mentioned).
However, given the quality of code in that tutorial (ie: a lowlevel setup
routine called by main.c instead of the startup code, no rule templates in
the makefile, but cut and paste makefile sections instead, as well as some
linker issues), I would double check the situation with this yourself if
you are thinking of using SAM-BA.
Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Reply by Stef●March 25, 20112011-03-25
In comp.arch.embedded,
Alexander Kane <ajpkane@gmail.com> wrote:
> I'm after a microcontroller with USB ISP right out of the box with
> support from the micro's regular tools.
> Important are a small footprint, though preferably not QFN or anything
> that can't be hand soldered, and that it is relatively cheap.
> This microcontroller doesn't need a whole lot of grunt, so an 8-bit or
> 16-bit would be fine.
> Thanks for your help.
Atmel SAM7S can be programmed through USB. Needs a special programming
application that can be downloaded from Atmel.
Atmel probably has newer controllers with USB programming, I have not
checked this recently.
--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)
For your penance, say five Hail Marys and one loud BLAH!
Reply by Arlet Ottens●March 25, 20112011-03-25
On 03/25/2011 04:15 AM, Alexander Kane wrote:
> I'm after a microcontroller with USB ISP right out of the box with
> support from the micro's regular tools.
> Important are a small footprint, though preferably not QFN or anything
> that can't be hand soldered, and that it is relatively cheap.
> This microcontroller doesn't need a whole lot of grunt, so an 8-bit or
> 16-bit would be fine.
> Thanks for your help.
LPC1342 (or 1343) comes to mind. Available in LQFP48, and has built in
boot ROM that can present itself as a USB mass storage device where you
can simply copy the firmware to.
Tools can be downloaded here:
http://lpcxpresso.code-red-tech.com/LPCXpresso/
(Free for small projects)
Reply by linnix●March 25, 20112011-03-25
On Mar 24, 7:18=A0pm, Alexander Kane <ajpk...@gmail.com> wrote:
> I should clarify: by regular tools I mean the software... the idea is
> to program the micro with just the USB cable (plugged into my board
> ofcourse), rather than a programmer device.
I should clarify: by regular tools I mean the software... the idea is
to program the micro with just the USB cable (plugged into my board
ofcourse), rather than a programmer device.