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?
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.
clawson 
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
