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

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

Hung Bui — Mon, 27 Apr 2015 12:30:30 GMT

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

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

riceman0 — Mon, 27 Apr 2015 06:00:39 GMT

Thanks for the help... the self-saving checksum worked, once I debugged my logic. I'm going with that solution.

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

Hung Bui — Thu, 23 Apr 2015 13:37:24 GMT

It depends on how you flash and reset the chip when programming. Most likely the chip got running after you flash it, before you enter debug mode. I would suggest you to debug using UART trace instead.

You have to make sure CRC calculation is not include the flash area that you store CRC checksum value. You can think of writing it to UICR area. What I'm seeing is that you are calculating the whole flash region with NVS_TESTPAGE*((uint16_t)NRF_FICR->CODEPAGESIZE) size. (except for UICR area)

Running the device in debug mode should make no different with running it in normal mode in term of functionality.

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

riceman0 — Thu, 23 Apr 2015 12:44:25 GMT

(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.

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

Hung Bui — Thu, 23 Apr 2015 09:26:34 GMT

Hi Riceman,

Please correct me if I'm wrong.

You want to generate a check sum and write it to flash in the factory testing process before it goes to the market. So that on normal operation when booting up it can check for flash integrity ?

I am not sure why you need to read it out via Serial at ( c)and then write it back at (d), why not checking if it's the first run (using a magic byte such as 0xBEEF) you calculate the crc, then write to flash the CRC. Of course the part of flash that you store the CRC should not be calculated for CRC.

Alternativelly, if you don't want to use the code to store the crc on flash, you can use the CRC calculating tool (crc.exe) to calculate the crc value and can use nrfjprog to write into flash on the nRF51.