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!)
AT91SAM7S Boot Assistant (SAM-BA)
Moderator: nferre
Post
flash new chip
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
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
- pfilippi
- Contact:
Post
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.
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.
Post
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!pfilippi wrote: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.

- reneske
- Location: Denmark
Post
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é
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é
Post
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.reneske wrote: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é
- bschiett
- Location: Belgium
Post
usb dfu? samba??
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
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
- pfilippi
- Contact:
Post
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.
Regards,
1. I heard about the USB DFU class but it's not clear whether the SAM7s supports this and how it would work
The SAM7S products do not support it.
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?
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.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?
Regards,
- bschiett
- Location: Belgium
Post
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?pfilippi wrote:Hi Bert,
1. I heard about the USB DFU class but it's not clear whether the SAM7s supports this and how it would work
The SAM7S products do not support it.
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?
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.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?
Regards,
- dwight
- Location: Silicon Valley
Post
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.
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.
Who is online
Users browsing this forum: Baidu [Spider] and 4 guests