glad to be of some help Mike
----- Original Message -----
From: ğlar Aky
To: A...
Sent: Thursday, October 05, 2006 4:05 AM
Subject: [AT91SAM] Re: Custom Board and SAM-BA
--- In A..., "mjdistl" wrote:
> my custom board works fine on samba with sam7x256
> make sure you have a 1.5k pullup resistor to 3.3v and pin
> 3 on usb conn. power up your board with erase pin pulled
> high. power down remove erase jumper. power back up and
> when windows finds new hardware load the 6124sys driver
> from samba.

Thanks everyone. From your words I understand that SAM-BA should
definetly work with my custom board and double ( even triple ) check
my board and find the problem.

Thanks mjdistl. Your suggestion for the pull-up gave me a great help.

Best Ragards,
ar

Guys guys guys,

So close,... but not quite there.

I dunno about the 7S series chips, but here's how the 7X256 works for
us (and the 7XC256 as well) for us.

The SAMBA boot code is stored in ROM on the 7X(C)256's. The GPNVM bit
(is it 2?) selects whether the ROM (default - GPNVM 2 erased), or
Application FLASH (GPNVM 2 programmed), is mapped in at 0x0000000 on
bootup. I can't remember if the ROM is mapped up somewhere higher up
in memory as well (and is therefore "visible" after the remap
instruction), but I'd be surprised if it isn't.

Now, if your installed application code has a means whereby it can
alter the GPNVM bit, (eg. via a command/password to a command shell
running on the serial port or whatever), you can jump back to the SAMBA
bootloader by simply clearing the GPNVM bit and resetting the micro.
You can get back to your application by using the SAMBA windows client
to reprogram the GPNVM bit and reset the micro (again!).

Failing that, if the SAMBA rom is accessible, and written in entirely
relocatable code, then you could possibly get away with a programmed
jump to the address and boot into SAMBA that way (assuming the ROM is
mapped into memory at run-time, AND that the rom based code doesn't
care what "base address" it runs from). You can then get back to your
application simply by resetting the micro.

Failing either of the above, THE ONLY WAY to get back to SAMBA is to
jiggle the power WHILE TYING THE ERASE pin (NOT the Tst pin!). This
WILL ALSO CLEAR your entire application flash and restore the GPNVM
bits to defaults, which says boot from SAMBA ROM on the next reset. You
WILL NOT be able to return to your application simply by flipping the
GPNVM bit because your flash has been erased! (However, you can of
course, re-download it using the SAMBA windows client).

As I said, I don't have any experience on the 7S series micros, so I
don't know if it's different for them in regards which pin you jiggle
and whether the ROM is visible or not, ... but the above description IS
how the 7X series work, because that's how we do it (including on our
custom board).

Does that clear it up fo' everyone?

Cheers,
David.

--- In A..., "mjdistl" wrote:
> my custom board works fine on samba with sam7x256
> make sure you have a 1.5k pullup resistor to 3.3v and pin
> 3 on usb conn. power up your board with erase pin pulled
> high. power down remove erase jumper. power back up and
> when windows finds new hardware load the 6124sys driver
> from samba.

Thanks everyone. From your words I understand that SAM-BA should
definetly work with my custom board and double ( even triple ) check
my board and find the problem.

Thanks mjdistl. Your suggestion for the pull-up gave me a great help.

Best Ragards,
ar

Hi,

the samba boot loader is stored somewhere in inaccessible flash on the
AT91SAM7S/X . Setting the TST pin (pin 40 on the processor) to Vdd
causes the samba code to be inserted in the main flash. After reset, the
samba code is executed from there.

This is pretty neat, allows one to download updates to the board without
writing a boot loader yourself.

Ewout
> Re: Custom Board and SAM-BA
> Posted by: "yttsai" y...@yahoo.com yttsai
> Mon Oct 2, 2006 9:26 pm (PST)
> Hello, Jim
>
> How to access the invisible onboard flash ?
> Is it possible to make it software trigger not shorting the TST jumper ?
>
> Best regards,
> Yu-Tsao
>
> --- In A..., "lynchzilla" wrote:
>>
>> Hi ar Aky:
>>
>> To make your board talk to the SAM-BA utility, you need a USB driver
>> installed on your board that interfaces to the SAM-BA command set.
>> With a virgin board, you don't have anything running.
>>
>> On the Atmel AT91SAM7S256-EK board you have, shorting the TST jumper
>> and applying power causes a USB driver and other boot software to be
>> copied from invisible onboard flash to address 0x00000000 on your
>> board flash. When you remove the TST jumper and restart, then this USB
>> driver starts running and you get the USB "beep" on Windows.
>>
>> Olimex boards do the same thing, so where did they get this USB driver
>> designed to work with SAM-BA?
>>
>> I believe that if you go to www.at91.com and go to the FAQ section,
>> the answer is in this FAQ question:
>>
>> How to Program the AT91SAM7A3 with SAM-PROG and SAM-BA ?
>>
>> I believe that the download referenced there is the code you need.
>>
>> Cheers,
>> Jim Lynch
>>

> user. However, I don't think that it's mapped into low memory, as the
> NXT/Philips LPC2000 chips are mapped to address 0x00 when a I/O pin is
> pulled high. Rather, this code is "programmed" into flash when the
> board is power-cycled with the TST jumper shorted. In fact, it also
> sets the lock bits.
>
> Using SAM-BA to program an application into flash memory is a
> destructive operation; SAM-BA becomes unusable after programming. You
> have to short the TST jumper and re-cycle power to get SAM-BA suport re-
> loaded again.

This is different for the AT91SAM7S and the AT91SAM7X.

The AT91SAM7S copies the hidden RAM to flash, pages 0 and 1, when you
use the magic power on sequence with the tst pin that remi describes.

The AT91SAM7X chips maps the SAM-BA code into low memory, without
changing the flash, when GPNVM bit 2 is set. This is nondestructive
and you can reflash the chip without affecting SAM-BA. The thing to
note is that a reboot takes us back to SAM-BA, not the new flash
image, until we unmap SAM-BA with GPNVM bit 2.

/Magnus

Well, it serves me right to try to answer a message board question way
past my bedtime. Yes, there's no "invisible" flash.The SAM-BA support
code is within onchip ROM memory that's essentially invisible to the
user. However, I don't think that it's mapped into low memory, as the
NXT/Philips LPC2000 chips are mapped to address 0x00 when a I/O pin is
pulled high. Rather, this code is "programmed" into flash when the
board is power-cycled with the TST jumper shorted. In fact, it also
sets the lock bits.

Using SAM-BA to program an application into flash memory is a
destructive operation; SAM-BA becomes unusable after programming. You
have to short the TST jumper and re-cycle power to get SAM-BA suport re-
loaded again.

Magnus has it right; you can get the SAM-BA support code programmed
into flash from the onchip ROM by setting the appropriate port pins,
etc. before cycling power.

Cheers,
Jim

--- In A..., ğlar Aky wrote:
>
> --- In A..., "lynchzilla" wrote:
> >
> > Hi ar Aky:
>
> Hi,
>
> > To make your board talk to the SAM-BA utility, you need a USB
driver
> > installed on your board that interfaces to the SAM-BA command
set.
> > With a virgin board, you don't have anything running.
>
> I always thought that this USB driver was in the internal factory
> programmed ROM of SAM7X.
>
> > On the Atmel AT91SAM7S256-EK board you have, shorting the TST
jumper
> > and applying power causes a USB driver and other boot software
to be
> > copied from invisible onboard flash to address 0x00000000 on
your
> > board flash. When you remove the TST jumper and restart, then
this USB
> > driver starts running and you get the USB "beep" on Windows.
>
> somebody shoot me!is there an invisible flash on EK containing SAM-
BA
> boot code? I totally discarded this option.
>
> If there is factory programmed ROM case,why not this also works
with
> my chip? Is this meaning that Atmel is shipping different chips for
> their EKs and for their end-users? If this is not the case, how
can we
> make it possible to copy contents of some external flash to the
SAM7X
> when we short the TST pin?
>
> > Olimex boards do the same thing, so where did they get this USB
driver
> > designed to work with SAM-BA?
>
> I wonder also how Olimex guys do this. I'm trying to bring-up my
own
> board, and I'm using the native sam-ba USB driver( if you mean
windows
> drivers ).
>
> > I believe that if you go to www.at91.com and go to the FAQ
section,
> > the answer is in this FAQ question:
> >
> > How to Program the AT91SAM7A3 with SAM-PROG and SAM-BA ?
> >
> > I believe that the download referenced there is the code you
need.
>
> So I understand from your words that I have to write my own boot
> program using AT91ISP. I wondered if I could do something simpler.
>
> Thanks for the reply.
> Best regards,
> ar
>
my custom board works fine on samba with sam7x256
make sure you have a 1.5k pullup resistor to 3.3v and pin
3 on usb conn. power up your board with erase pin pulled
high. power down remove erase jumper. power back up and
when windows finds new hardware load the 6124sys driver
from samba.

Maybe this can help you:

to load factory ROM SAM-BA to internal flash.

TST pin to 3.3v
PA0 pin to 3.3v
PA1 pin to 3.3v
PA2 pin to 3.3v (If any of these PAx pin is unconnected, internal pull-up tied already to 3.3v, your TST to short to 3.3v)

Power up your board for 10 seconds.

Power down board, remove TST and PAx jumper, can be unconnected.

Power up your board and sam-ba is running USB and serial.

Remi Bilodeau - Technicien en ectronique
UQAT - Universitdu Quec en Abitibi-Tiscamingue

________________________________

De : A... [mailto:A...] De la part de Magnus Lundin
Envoy: 3 octobre 2006 04:52
: A...
Objet : [AT91SAM] Re: Custom Board and SAM-BA

SAM-BA is factory installed in ROM on the chip. The two things to check
are the GPNVM bit 2 and the crystal frequency 18.432 MHz for USB.
(This clock requirement is only for SAM-BA not for your own
USB applications, only a 48MHz peripherial clock is necessary)
You can also try to use SAM-BA with the serial DBGU port.

>From the AT91SAM7X256 documentation:

The SAM-BA Boot Assistant is a default Boot Program that provides an
easy way to program insitu
the on-chip Flash memory.
The SAM-BA Boot Assistant supports serial communication via the DBGU
or the USB Device
Port.
* Communication via the DBGU supports a wide range of crystals from 3
to 20 MHz via
software auto-detection.
* Communication via the USB Device Port is limited to an 18.432 MHz
crystal.
The SAM-BA Boot provides an interface with SAM-BA Graphic User
Interface (GUI).
The SAM-BA Boot is in ROM and is mapped in Flash at address 0x0 when
the GPNVM Bit 2 is
set to 0.

SAM-BA is factory installed in ROM on the chip. The two things to check
are the GPNVM bit 2 and the crystal frequency 18.432 MHz for USB.
(This clock requirement is only for SAM-BA not for your own
USB applications, only a 48MHz peripherial clock is necessary)
You can also try to use SAM-BA with the serial DBGU port.

>From the AT91SAM7X256 documentation:

The SAM-BA Boot Assistant is a default Boot Program that provides an
easy way to program insitu
the on-chip Flash memory.
The SAM-BA Boot Assistant supports serial communication via the DBGU
or the USB Device
Port.
Communication via the DBGU supports a wide range of crystals from 3
to 20 MHz via
software auto-detection.
Communication via the USB Device Port is limited to an 18.432 MHz
crystal.
The SAM-BA Boot provides an interface with SAM-BA Graphic User
Interface (GUI).
The SAM-BA Boot is in ROM and is mapped in Flash at address 0x0 when
the GPNVM Bit 2 is
set to 0.

--- In A..., "lynchzilla" wrote:
>
> Hi ar Aky:

Hi,

> To make your board talk to the SAM-BA utility, you need a USB driver
> installed on your board that interfaces to the SAM-BA command set.
> With a virgin board, you don't have anything running.

I always thought that this USB driver was in the internal factory
programmed ROM of SAM7X.

> On the Atmel AT91SAM7S256-EK board you have, shorting the TST jumper
> and applying power causes a USB driver and other boot software to be
> copied from invisible onboard flash to address 0x00000000 on your
> board flash. When you remove the TST jumper and restart, then this USB
> driver starts running and you get the USB "beep" on Windows.

somebody shoot me!is there an invisible flash on EK containing SAM-BA
boot code? I totally discarded this option.

If there is factory programmed ROM case,why not this also works with
my chip? Is this meaning that Atmel is shipping different chips for
their EKs and for their end-users? If this is not the case, how can we
make it possible to copy contents of some external flash to the SAM7X
when we short the TST pin?

> Olimex boards do the same thing, so where did they get this USB driver
> designed to work with SAM-BA?

I wonder also how Olimex guys do this. I'm trying to bring-up my own
board, and I'm using the native sam-ba USB driver( if you mean windows
drivers ).

> I believe that if you go to www.at91.com and go to the FAQ section,
> the answer is in this FAQ question:
>
> How to Program the AT91SAM7A3 with SAM-PROG and SAM-BA ?
>
> I believe that the download referenced there is the code you need.

So I understand from your words that I have to write my own boot
program using AT91ISP. I wondered if I could do something simpler.

Thanks for the reply.
Best regards,
ar