Alas, the .exe cannot be extracted with the latest version of both Fedora and Wine. So I have no idea what's on that release.

I did, however, find the SAM-BA doc, and have some questions. First, where does the related code that SAM-BA talks to live on the Eval board? I didn't see the memory map mentioned in the doc.

Secondly, is the source code to the binary which gets put on the Eval board available? Or is this included in the .exe file? The reason why I ask is because I'm doing something similar with Redboot, and am interested in making this work for those with Linux development systems.

Finally, I noticed from the doc that the SAM-BA GUI all seems to be written in TCL. If this is the case, then the GUI ought to run right out of the box on Linux. TCL was originally developed for UNIX, and has been an integral part of UNIX/Linux for many, many years.

Well, that's actually an amusing question. If I read the doc correctly, it indicates that the code is written in TCL. If that's the case, then you already have the source code. Personally, I have no idea, as I can't extract the stuff to see what's actually there.

What's also amusing (and useful) if this is true is that the TCL code ought to work on Linux as well as Windows. TCL was originally designed and written soley for UNIX, and consequently Linux. It was only much later that it was ported to Windows.

So if we could get some clarity on these issues, we might be able to expand the support of Atmel's processors across different platforms, and make it more available for more people.

I read in the errata for the chip that the lock bits can only be changed 100 times. Running the recovery proceedure unlocks and then locks the first two regions, then you would have to unlock them to program the flash. That is three changes of the lock bits. Does that mean you can only use the procedure about 33 times? I hope I am wrong, I really like the way SAM-BA works.

Hi, are the chance that you release fireware for SAM-BA....
I think it would be a good application note..

Any way, are any cheap Jtag flash tools? IAR STK lock great but (and it is relativt cheap) but it lock like you have to buy J-Flash software (398â‚¬) or IAR compiler if want to flash more 32Kb... or do I miss something?

And SAMBA only works AT91SAM7S128 rev C and higher....
(And it lock like www.elfa.se only have rev B of AT91SAM7S128 (but the only sell AT91SAM7S64))
and I can not get chip that support SAM-BA, so I begin to regret my choice of microcontroller....

I got this error using SAM-BA:
-I- File size = 65536 byte(s)
-E- Memory Overflow
Chip AT91SAM7S64 Program Flash using rawBinary file from IAR compiler and Fill all memory with ones (0xFF).
This creates a full flash of 64K right ?
Send file to Flash start at address 0x0100000

It works OK if I delete a byte from the file but there is an EOF marker (0x0A) at the end of the file that is included with the binary image and programed into the chip (last byte).
If the (0x0A) is removed the file will not work.

Any way, are any cheap Jtag flash tools? IAR STK lock great but (and it is relativt cheap) but it lock like you have to buy J-Flash software (398â‚¬) or IAR compiler if want to flash more 32Kb... or do I miss something?

Yes, Embest tools provider form ARM, provides a flash programmer for 80$ and schematics to do a JTAG cable (wiggler compatible) which will cost you around 5$.

You are not wrong, this is one bug which was already found and corrected in the nearly new versions we will provide very soon !

Bye,

I got this error using SAM-BA:
-I- File size = 65536 byte(s)
-E- Memory Overflow
Chip AT91SAM7S64 Program Flash using rawBinary file from IAR compiler and Fill all memory with ones (0xFF).
This creates a full flash of 64K right ?
Send file to Flash start at address 0x0100000

It works OK if I delete a byte from the file but there is an EOF marker (0x0A) at the end of the file that is included with the binary image and programed into the chip (last byte).
If the (0x0A) is removed the file will not work.