2

Due to the current chip shortage, I have had to purchase PIC microcontrollers that have a different specification to what was initially designed.

  • Initial: PIC24FJ256GA606
  • Revision 1: PIC24FJ512GA606
  • Revision 2: PIC24FJ1024GA606

In this instance, the microcontrollers are within the same family but have different size of memory.

Initially, the binary was created to support multiple product variants and they all use this microcontroller (using hardware pins to define the type of product and thus the software features it supports). I would like to continue with a single binary but to be able to support the different microcontrollers specified above.

We flash the microcontrollers using a PICKIT 4 during manufacturing. A custom bootloader is also flashed onto the microcontroller during manufacturing to allow the firmware update procedure to be is driven by another PIC microcontroller out in the field (it's a distributed system connected by RS-485).

I use MPLAB X IDE for development and buildings production binaries.

I guess the key question is about if this is even possible? If so, then how would I achieve creating the single binary that supports multiple processors?

wntwrk
  • 317
  • 1
  • 2
  • 10
  • 1
    It’s a fair and well written question. My guess is the binary mapped for the smallest should work on all three. Worth testing. – jolati Dec 21 '21 at 00:21
  • I guess you will always get a controller mismatch. So the programer won't detect the correct chip and won't start- But yes, the question is good. – Mike Dec 21 '21 at 05:45
  • If only the memory size is the difference, why do you think will the binary **not** run on the bigger devices? – the busybee Dec 23 '21 at 09:34

2 Answers2

1

Normally a single binary should only correspond to the specific controller. Because especially Microchip has really wide variaty of microcontrollers. But as you mentioned in your question:

In this instance, the microcontrollers are within the same family but have different size of memory.

You can slightly use the same binary as long as you select the hardware very carefully. I mean if those 3 different models has the same pin mapping but some has less or some has more, then you would select the common corresponding pins for the I/O functions wherever possible. Since those devices are from the same family they must have common IO pins with the same port and pin numbering.

If those similarities including of that the internal registers are enough for the functionality of your system, you can use the same binary for those 3 or more devices as long as you select the right hardware very carefully and none of the functions remain without touching its hardware.

But it is very hard to say the same for the others that are not belong to a series in the same family. In this case you can check the hardware similarities for each functionality of your system. If that micro provides the same hardware, then you can go and firstly give it a try to see whether it will be programmed and then it will funtion in the same way. After making sure enough you can add that model in your usable models list, too.

Hope this give you a helpful idea.

Kozmotronik
  • 2,080
  • 3
  • 10
  • 25
1

For two microcontrollers to have compatible binaries, they need to fulfil the following:

  • The CPU cores must have identical Instruction Set Architecture. Be aware that the term "code compatible" by the manufacturer might only mean that two parts have the same ISA and are compatible on the assembly language level, as long as no peripherals or memories are used...
  • In case they have different memory sizes, the part with larger memory must be a superset of the part with smaller memory and they must map memory to the same addresses.
  • All hardware peripherals used must be identical and any peripheral routing registers used must also be identical. Please note that the very same core of the same family but with a different package and pin routing might mean that peripheral routing registers must be set differently.
  • There can be no check of MCU partnumber registers etc inside the firmware, nor can there be any in the flash programming equipment.

In general this means that the MCUs must be of the very same family and the manufacturer must guarantee that they are replaceable.

You can very likely switch between different temperature spec parts of the same model and between automotive/non-automotive qual parts of the same model without changing the code.

Lundin
  • 195,001
  • 40
  • 254
  • 396