Keil uVision 5+nRF51822+BLES110 softdevice: best way to implement a checksum at compile/build time?

[riceman0]

Hello, I have inherited a (good) project in which the previous designer implemented a checksum using a value calculated from this:

char* pMemory = 0; return crc16_ccitt(pMemory, NVS_TESTPAGE*((uint16_t)NRF_FICR->CODEPAGESIZE));

Her firmware compares this during startup against a value retrieved from flash memory. Then she designed an install process in which you (a) install the firmware, (b) run it and let it fail the checksum (which puts it into our FAULT state), (c) use a serial maintenance tool (which talks to our code which is enabled in FAULT) to query the above code, then (d) use the serial tool to send the proper checksum value back into the device to be written to flash, and when you cycle power it passes the checksum.

We are trying to streamline this process so that we dont need the serial tool (accessing the serial port has caused a manufacturing issue), and we can get the proper checksum value in there at build time (I presume she did the above because it you store it in source code, changing it changes the needed checksum and its a catch 22). I see enough hits for this to convince me it's possible, but can't find a solution that works for our compiler+target.

Can anyone recommend an approach or point me to some sample code?

Thanks VERY much for any help.

[riceman0]

(this is a response to hungbui, in case I mis-posted... thank you)

Actually thank you, I had a similar thought (just have it self-program on the first run) shortly after I hit "submit." :) So I tried exactly that, created a new flash storage item, and checked it for a NOTFIRSTRUN magic number, and if it is the first run, calc and set the CRC. That doesn't seem to work either though, here's my experience:

I never see the FIRSTRUN logic path fire... I think this must be because my firmware actually runs once or twice before I can actually get into debug mode. Does that make sense?

Second, even though NOTFIRSTRUN is "mysteriously" set, the subsequent CRC checks fail. My theory is that this is because the CRC calculated in debug mode is different than the CRC calculated in release mode? Does that make sense too? Can I expect this to work in release mode then?

Also I assume that the crc calculated with this

crc16_ccitt(pMemory, NVS_TESTPAGE*((uint16_t)NRF_FICR->CODEPAGESIZE));

does NOT span flash memory accessed via API functions like

ble_flash_page_write

is that right? Otherwise her logic never would have worked, she would break the CRC every time she reconfigured.

[Hung Bui]

@riceman: Good to hear. If you are ok with the answer, could you accept the answer to close the case.