Scripting to automate projects with microchip tools

Question

• IDE: MPLAB IDE 8.87
• Compilers: C30/ASM30
• Debugger/Programmer: MPLAB ICD 3
• Windows 7

Question: I have utility projects such as clearing an EEPROM on custom hardware, retrieve data from an IC, and so on. I would like to be able to automate the procedure for such tasks.

Example: Clear EEPROM.

• Input to script: Start location, number of bytes, EEPROM physical Address
• Output from script: Selected range deleted successfully/Failed

The steps for this will be to build and link project with the input information, program the uController connected to the debugger, execute code, validate for successful completion and inform the user of the outcome.

How can I write scripts like this?

I have no experience of previous scripting, and this question is motivated simply to avoid wasting time in the future.

Kind Regards,

Answer 1

You can't really script the IDE. It's not designed for that. You can of course run the compiler, assembler, librarian, and linker directly without using the IDE. In fact, this is how I build all my PIC projects. I use the IDE only for debugging. The reason I do this is to allow for automatic builds of PIC firmware as part of a larger process, and to apply some of my own tools in the chain from source code to HEX file. For example, I run all my ASM30 and MPASM source code thru my preprocessor.

For how to run the various tools directly, read the manual, which in this case is MPLAB ASSEMBLER, LINKER AND UTILITIES for PIC24 MCUs and dsPIC DSCs User's Guide, DS51317.

However, rebuilding the firmware each time sounds more complicated than necessary. If you are only changing some data at a known location in program memory, then you can do this with a simple HEX file editing program. I do this sort of thing occasionally, often to create a HEX file with a unique serial number from a master HEX file. I make a program that reads in a HEX file into arrays in memory, usually one for executable program memory, config bits, EEPROM initial data, and user ID locations. The program then modifies the data as necessary, and writes the result out to a new HEX file.

It's usually a good idea to put firmware info at a known fixed address when doing this. I usually put the firmware type ID, version number, and sequence number in the three bytes of the program memory word at 800h. That is far enough into executable code so that the section between start and 800h is large enough to utilize efficiently, but not so far as to be past the end of program memory for any reasonable PIC. You make this a fixed code section and let the linker place relocatable sections around it. Here is a example from a recent project:

;*******************************************************************************
;
;   Constants in program memory so that HEX file editing tools know the version
;   of this firmware.
;
.section .fwinfo, code, address(0x800)
         .pword  fwtype | (fwver << 8) | (fwseq << 16)

This allows the HEX file tool to veryify that it is working on the right type of HEX file, and to display this information at run time.

Answer 2

You can indeed write your own custom tools for that. Calling the microchip tools from command line is not trivial and you probably have to make a (worth) effort of setting up everything.

I made several of these and I can say that:

1. It is remarkably useful to learn some scripting language like Python, Perl, etc;
2. Having deep knowledge of windows batch files or shell scripting in Linux also helps a lot;
3. Writing custom tools helps you learn the entire process;
4. It is worth to invest time creating a decent build system, specially if the firmware is part of a larger project (think Scons, CMake, etc);

For your specific needs, you can create a small program that uses a C-define for changing the address of whatever you want to change the address. How is the EEPROM cleared? The MCU sends commands to it? Why don't you write yourself a fancy GUI tool for that that communicates with a service-firmware (or put your current firmware in service mode, if there is room for that)? You just need a working RS232 to do that.

I'm a big fan of writing custom code to make processes quickier and less error prone.