Writing to micro using atprogram.exe

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

For my project, I need the ability to write to ATxmega32D4 microcontroller using the CLI atprogram.exe from a Windows desktop software. I'm using the following C# code to write to the flash memory:

 

for (int offset = 0; offset < data.Length; )
{
    int subdata_length = Math.Min(30000, data.Length - offset);
    string subdata = data.Substring(offset, subdata_length);

    psi.Arguments = " -t " + flasherTool + " -i PDI -d " + mcutype + " -cl " + frequency + " write -fl -o " +
        String.Format("0x{0:X}", offset) + " --values " + subdata + " ";
    pcs = Process.Start(psi);
    pcs.WaitForExit(5 * 60 * 1000); // Maximum wait upto 5 minutes
    output += pcs.StandardOutput.ReadToEnd();
    offset += subdata_length;
}

 

The type of data is a string. It is structured based on a hex file. It's size is 34,612 so I'm breaking it down and sending using atprogram.exe. The statement Process.Start(psi) will start atprogram.exe using psi.Arguments. I've checked the output variable. It says firmware is OK and write is successful.

 

I'm verifying if the hex file is written successfully using Atmel Studio 7.0's Device Programming window. When I do that, Atmel Studio tells that verification fails.

 

 

If I write the hex file using Device Programming window, it is written without error and if I verify, it says verification is OK.

 

What could be the error in my approach?

 

Thanks.

 

adrahman

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What happens if you use the interim step:

 

1) use the command line atprogram.exe but

 

2) don't try driving it with C#. Just type the command on the command line.

Does that work? If it does is the typed command 100% identical to what is programmatically generated in the C# ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Windows doesn't allow my to write ~30K characters in command prompt.

adrahman

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why in the name of all that is holy are you doing it like that? Why not simply create a .hex file then tell atprogram to program it? Just delete the "temp file" afterwards if leaving it behind is considered "messy".

 

In fact what you could even do is auto-gen a C file then compile/link/objcopy that from within the C# to create the .hex to be used in atprogram

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm a maintenance developer for the project. The previous developer read the hex file and generated a list of hex digit to be fed into atprogram.exe. In the process, it looks like it modifies the hex file in a way I don't understand. There is no comment or document for that - I don't know if it is even a modification, or something else. So I don't intend to change the way it works.

 

All I have left to work with is a stream of hex digits (nibbles) that needs to be fed into atprogram. How can I reverse it to a hex file?

adrahman

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

adrahman wrote:

I'm a maintenance developer for the project. The previous developer read the hex file and generated a list of hex digit to be fed into atprogram.exe. In the process, it looks like it modifies the hex file in a way I don't understand. There is no comment or document for that - I don't know if it is even a modification, or something else. So I don't intend to change the way it works.

 

All I have left to work with is a stream of hex digits (nibbles) that needs to be fed into atprogram. How can I reverse it to a hex file?

 

When you say "hex", do you mean a binary file (e.g. with .bin extension) or an Intel HEX file, which is a text file? If you have .bin, you can convert it easily, this question has been answered many times in this forum, for example: http://www.avrfreaks.net/forum/how-convert-bin-file-hex-file

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's the Intel hex file.

adrahman