Does Atmel Arm 7 Use S Records to Flash?

Go To Last Post
3 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have inherited a project for an arm 7 (Atmel AT91SAM7S256) with an IAR workbench IDE.  I have noticed that I can flash this micro through the J-Link probe, with motorola type files (.mot).  I assume this is some sort of s-record format. I imagine it uses s-record because it has a risk architecture.  There is also another DFU startup code that allows for USB flashing with what I believe is a raw-binary format.  My question is how can this micro be flashed with two different types of binary images?

 

Thanks,
Will

Last Edited: Thu. Apr 7, 2016 - 12:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

They are two different representations of the same thing. The code driving the jlink will convert the s-rec to binary. The dfu expects a binary file. It all ends up as binary in the device's flash.
RISC or CISC had nothing to do with the file type. Srec was around in the 70's - mainly for paper tape as was Intel hex. RISC didn't come about until the 80's.

Last Edited: Thu. Apr 7, 2016 - 04:17 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

wkhan69 wrote:
I imagine it uses s-record because it has a risk architecture.

Interesting non sequitur! How on earth does "risc" mandate s-record then?

 

Anyway presumably the thing that is driving DFU at the PC end, that takes the input files is Atmel FLIP 3? As far as I can see FLIP accepts two input formats; either Intel Hex or "A90" (which is an IAR format).

 

Anyway as Kartman says you can have the same binary in multiple formats, for example:

$ hexdump -e '16/1 "%02X ""\n"' file.bin
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
04 98 97 00 01 20 03 3D 08 00 0A 20 02 30 D3 00
64 20 02 18 69 00 C8 20 01 27 0F 00 01 6B 01 20
8C 04 A5 20 01 1A 09 05 DC 20 01 13 87 00 02 6B
01 07 CF 00 05 6B 01 03 E7 00 0A 6B 01 01 F3 00
14 6B 01 00 C7 00 32 6B 01 00 63 00 64 6B 01 00
31 00 C8 6B 01 00 13 01 F4 6B 01 00 09 00 01 4D
01 00 04 00 02 4D 01 00 02 0D 05 6B 01 00 01 00
05 4D 01 00 00 00 0A 4D 00 00
$ objcopy -I binary -O ihex file.bin file.hex
$ cat file.hex
:1000000001000000000000000000000000000000EF
:10001000049897000120033D08000A200230D30015
:10002000642002186900C82001270F00016B01201D
:100030008C04A520011A0905DC2001138700026B3E
:100040000107CF00056B0103E7000A6B0101F30014
:10005000146B0100C700326B01006300646B010088
:100060003100C86B01001301F46B01000900014D60
:1000700001000400024D0100020D056B01000100AA
:0A008000054D010000000A4D0000CC
:00000001FF
$ objcopy -I binary -O srec file.bin file.srec
$ cat file.srec
S00C000066696C652E7372656378
S113000001000000000000000000000000000000EB
S1130010049897000120033D08000A200230D30011
S1130020642002186900C82001270F00016B012019
S11300308C04A520011A0905DC2001138700026B3A
S11300400107CF00056B0103E7000A6B0101F30010
S1130050146B0100C700326B01006300646B010084
S11300603100C86B01001301F46B01000900014D5C
S113007001000400024D0100020D056B01000100A6
S10D0080054D010000000A4D0000C8
S9030000FC

That's exactly the same data as (a) raw binary, (b) Intel Hex, (c) Motorola Srecord

Last Edited: Thu. Apr 7, 2016 - 08:48 AM