Thanks for the quick reply.

If the ERASE line is raised, I assume SAM-BA can always be recovered? Also, if the security bit is set, I assume that the code will not be overwritten with SAM-BA if a system recovery is attempted?

Also, the SAM-BA docs say that four lines need to be set to recover SAM-BA: TST, PGMEN0, PGMEN1, and PGMEN2. But it says that there are pull-ups enabled by default on PGMEN0-2 on the SAM7S-EK. I'm confused about why this matters since any initialization code that enables the pull-ups on the PGMEN0-2 lines would be overwritten upon the first reflash of the chip. The SAM7S datasheet doesn't mention anything about these lines having pull-ups enabled by default upon reset in the hardware itself.

So to clarify, I need to manually pull up ALL 4 lines (TST, PGMEN0, PGMEN1, PGMEN2) before reset to successfully enter system recovery. Is this correct? This just seems like a lot since I need to keep these lines separated normally, and then all pulled high when I want to perform a system recovery (needing four switch circuits!)

Can anybody comment on the requirement of all 4 TST/PGMEN0/PGMEN1/PGMEN2 lines needing to be externally pulled high to enter system recovery? I'm laying out a board as we speak and would like to get it out tomorrow morning. Thanks guys!

Hello,

I have my own board with a new SAM7S64 populated rev.g, but I can not get the part flashed.
Checking the JTAG signals the Jlink does send out a init phase, but the controller has no feedback, same goes from the SAM-BA program.
I scanned through the AT91 CD but could not find anything telling me how to set up for a new device. I guess a miss a step here.
Has anybody experience how to do that?
Thank you
..richard

Hi Jimbotko,

like stated in table 4.1 p.7 (doc 6070b.pdf), PGMEN0, PGMEN1, and PGMEN2 are multiplexed respectively with PA0, PA1 and PA2, and PA[0:2] have intenal pull ups enabled by default. Pull ups are always available regardless the mode of the pin, i.e. driven by the PIO or by the multiplexed peripheral.
We have no switches on the SAM7S-EK
Bye,

Patrick.

Ah, silly me, I didn't read the generic PA[0:31] section where it specifies that they ALL have pull-ups enabled upon reset! You are the best, Patrick!

Another Silly me. Checked the hardware again and found my intended VDDCORE short was open, well well. At least the eval board works now

Do you need the erase the flash by asserting the ERASE pin before each execution of a system recovery?

No you don't.

bye

Yay for SAM-BA!

Hi

Is it posible to call samba from the program in flash memory or ram.
So it would work like a bootloader.

I would like to use it for developement purpose, and I think it take to much time to short the TST pin and wait 10 sec. each time I want to flash it.

Regard
René

Nope, it is purely design as a system recovery / last resort sort of thing. You're expected to write your own bootloader if you want specific functionality.

hi all,

I'm trying to understand what the various options are to upgrade the firmware if i would ship a product based on the at91sam7s64 or 256 ...

1. I heard about the USB DFU class but it's not clear whether the SAM7s supports this and how it would work

2. i looked at the sam-ba program and if I understand correctly it's a thing of last resort and should not be used to upgrade firmware for additional functionality or bug fixes?

3. so what is the best way to allow for firmware upgrades over usb then? implement DFU ourselves? do all OSes support it? or implement HID or some other class standard and transfer firmware upgrades e.g. through endpoint 0?

thanks in advance!
bert

Hi Bert,


The SAM7S products do not support it.


Actually, SAM-BA just allows you to program the flash. SAM-BA is not a firmware. It is just a recovery and programming tool for production.


I will say DFU.

Regards,

but to support DFU, my usb device would have to comply with the DFU class which means I need to implement this bug-free on the sam7s? and then I still need to write a driver for all platforms i want to support (win xp, mac osx, linux etc) before I can write an app that will communicate with the driver to upgrade the firmware?

Thanks for the release of SAM-BA.


Would it be possible in the future to please release self-extracting packages in a format which isn't .exe? This adds a burden to a good number of Linux users, because not all distros (and even fewer installs) include Windows emulators. Fedore Core 3, for example, which is one of the biggest Linux distros around.