Posted on May 28, 2015 at 22:10
One of your problems here is an over dependency on tools other people have written.
Here we write our own production programming software. The ST-LINK wouldn't be my route of choice, but I seem to recall ST providing a library level interface for it some while back, and people like Segger have DLL and libraries for their programmers.
If your task was to simply removed the edit/compile/link steps you should be able to take a .ELF, .BIN or .HEX and modify it or sign it on a per processor basis. If you want this to be remotely efficient you're going to have to automate the process.
Signing and encrypting a firmware image can get quite involved, so I'll stick here with just a small chip/board unique structure that can be filled in by a suitably coded programming station.
typedef struct _SIGNFOO {
uint32_t Signature;
uint32_t Size;
uint32_t Identifier[3];
// Other assorted stuff filled in by production programmer added here
uint32_t Checksum;
} SIGNFOO;
void CheckChipUnique(void)
{
static const SIGNFOO SignFoo = { 0xDEADBEEF, sizeof(SIGNFOO), 0x12345678, 0x9ABCDEF0, 0x87654321, 0 };
uint32_t i, sum;
uint32_t *p = (uint32_t *)&SignFoo;
sum = 0;
for(i=0; i<((SignFoo.Size / sizeof(uint32_t)) - 1); i++)
sum += *p++;
if (sum != SignFoo.Checksum)
{
puts(''Intergity Check Failed'');
return;
}
// Perform chip unique configuration and verification
}
int main(void)
{
CheckChipUnique();
while(1);
}
