Writing a data file to PIC FLASH memory

[Ground_Loop]

Is there a way through MPLAB X and a PICKIT 4 to write a data file to PIC Flash memory.  The intent is to write 1000 16-bit data words from a data file to FLASH memory in a PIC24.  This is less about the particular PIC than than the versatility of MPLAB and PICKIT.  If not MPLAB/PICKIT is there another tool.  My other options are to capture the data with the PIC into an array then store the array in FLASH, or write the file to an external memory chip that the PIC can read.

[Ian.M]

Use the third party utility SRecord as a pre-build step in your MPLAB X project to convert your binary datafile to something MPLAB  X can handle as part of your project.

You've got two choices, *EITHER*:

Tell SRecord to convert the data to an IntelHEX file (in the same IntelHEX format as the XC16 linker outputs,  IIRC its bigendian INHX32 with each 24 bit word padded with a zero high byte), and add the resulting hex file to the project as a loadable. You'll aslo need a definition for an array at an absolute address at the load address of the hex file and to reserve that memory area in the linker options.   If you need to (scriptably) tweak the  hex file, use the HEXMATE utility, (bundled with MPAB X and with XC8, documentation in XC8 manual), which is a 'Swiss army knife' for IntelHEX files.

*OR*:
Tell SRecord to convert the data to a source file containing a C array you can add to your project.  You'll probably need to add some other stuff to the array source, and the easiest way to do so is to have a 'stub' C file that #includes any headers you need, then #includes the generated file, then does any other macro 'magic' required e.g. define a const for the data length using sizeof  on the array.

N.B. MPLAB gets very mixed up and will try to make it twice resulting in duplicate definitions if you add a .c file to your project and also #include it.  Although its legal C to #include a .c file, you are strongly advised to name it whatever_c.h  to keep MPLAB happy.

[dmendesf]

Is your program written in C? If so it may be easier to embed the data in the source code.

[Ian.M]

Embedding the data manually in your source code is fine for a one-off if you can be certain the data will never change, and accurately document how it was generated, but it will bite you in the ass if the data isn't set in stone.  You will wish you'd taken the time to script it properly so it's automated as part of the build process when you've had to re-do it manually several times.  By the third time a colleague needs you to re-explain how to do it manually, you'll want to shoot Dmendesf for his suggestion!

If you need to write a script to process the data anyway because its not directly human readable, you might as well do it right and make it part of the build process.   However I must confess to a tendency to doing quick&dirty one-offs in MS Excel, using its string functions to generate sourcecode for a C array in a column I can just copy/paste into a source file.

[Ground_Loop]

This is all just hobby/personal entertainment stuff,  but I like the idea of building the array in Excel. Once I have a good array I can push it either into a protected memory area or an external chip. Thanks for the replies.