CRC Mission Impossible

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
EdHa_4455331
Level 5
Level 5
25 replies posted 25 sign-ins 10 replies posted

I thought this was going to be easy but....

We are doing code for a medical device. For hazard control, the application software has to validate itself during the power-up initialization sequence.  So I said "we can just use the DFU SDK and include code something like:

     status = Cy_DFU_ValidateApp(0u, &dfuParams);

     if( status == CY_DFU_SUCCESS )

     {

          // Code image is good.

    }

   else

     {

          // Code image is bad.

    }

Now here is the gotcha - there is no bootloader in the system. We just want to download a hex file that includes the cymcuelftool generated CRC and let the above code find  that checksum and do the CRC check.

The problem we are running into is that there doesn't seem to be any way to get the checksum incorporated into the hex file and download to the MCU's flash by PSOC Creator 4.3.

We tried to be clever and use the cymcuelftool to append the CRC into the hex file by doing

cymcuelftool.exe -- signed App0.hex CRC -output App0.hex

But that still doesn't seem to get the CRC downloaded into flash, either.

Can anybody suggest how to generate a CRC for a non-bootloader App0, get that CRC download as part of programming App0 via PSOC Creator, and then checking that CRC at run time?

An alternate approach would to be somehow directly download the signed dfu cyacd2 file via a MiniProg4 pod (remember, there is no bootloader). Seems like there would be a PC tool to do this as the last step in a manufacturing operation. But I can't find any way to do this either. Is this possible? If so, what is the tool?

Thanks,

Ed H.

0 Likes
1 Solution

Thank you Motoo. I had already read over that doc, but your post prompted me to read it again (and again and again) until I understood every part of it. That did give me one of the clues that I needed. But there is one very non-obvious step in the solution that was not covered there or anywhere else.

In case there are any other poor souls out there that need to do this, here is how its done.

First, you have to add the signature section to main_cm4:

CY_SECTION(".cy_app_signature") __USED const uint32_t cy_dfu_appSignature[1];

Now, that SHOULD have been enough to get the job done. At the end of its build process, Psoc creator will run the cymcuelftool to fill in all of the dfu/crc sections that are included in the code. But the options it uses fails to fill in the signature (a.k.a. the 32 bit CRC of the code image) the cy_app_signature section:

ELF section .cy_app_signature found, but no hash specified. Skipping application signature

But... even if this had worked, it would not have been the final solution because where it only performed on the image fore the m4 core and not both the M0 and M4 cores (we want to verify both).

The previously mentioned signing step produces a "_signed.elf" version of the merged images and a ".hex" version of the merged images. If you try debugging at this point, Psoc Creator downloads the ".hex" version of the (incompletely signed) image of the code and the signature will still be 0x00000000.

So... to fix that, the big secret trick is to add the following to post_build_core1.bat file:

"C:\Program Files (x86)\Cypress\PDL\3.1.2\tools\win\elf\cymcuelftool.exe"

--sign %OUTPUT_DIR%\%PRJ_NAME%%ELF_EXT% CRC --hex %OUTPUT_DIR%\%PRJ_NAME%.hex

This repeats the signing process, but this time the CRC option is included and the signing process will succeed. It also clobbers the .hex file produced by Psoc Creator and replaces it with one that actually contains the signature.

There is one other "gotcha" to watch out for. The space allocated if flash for the core0 and core1 parts of the code have to be contiguous and completely fill the two regions:

    flash_app0_core0  (rx)  : ORIGIN = 0x10000000, LENGTH = 0x30000

    flash_app0_core1  (rx)  : ORIGIN = 0x10030000, LENGTH = 0x30000

If you used

    flash_app0_core0  (rx)  : ORIGIN = 0x10000000, LENGTH = 0x10000

    flash_app0_core1  (rx)  : ORIGIN = 0x10030000, LENGTH = 0x30000

the CRC will probably not be correct.

View solution in original post

3 Replies
EdHa_4455331
Level 5
Level 5
25 replies posted 25 sign-ins 10 replies posted

Well, I've been digging for another day, and I feel like I've know most of the puzzle parts. It appears that Cy_DFU_ValidateApp() expects the last four bytes in the flash region allocated to an app to contain an CRC of the rest of the area allocated to the app.

That SHOULD make things easy, but when I look at that memory location using the memory window, those four bytes are always zero.

So, why isn't a CRC being loaded into the last 4 bytes? How can I force the PSOC Creator to do this?

Thanks,

Ed H.

0 Likes
MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

Hi,

I wonder if AN213924 can be some help.

https://www.cypress.com/file/385706/download

I found this from the URL below. (It seems has more links to related information)

https://www.cypress.com/documentation/code-examples/ce220959-psoc-6-mcu-ble-bootloader-external-memo...

moto

0 Likes

Thank you Motoo. I had already read over that doc, but your post prompted me to read it again (and again and again) until I understood every part of it. That did give me one of the clues that I needed. But there is one very non-obvious step in the solution that was not covered there or anywhere else.

In case there are any other poor souls out there that need to do this, here is how its done.

First, you have to add the signature section to main_cm4:

CY_SECTION(".cy_app_signature") __USED const uint32_t cy_dfu_appSignature[1];

Now, that SHOULD have been enough to get the job done. At the end of its build process, Psoc creator will run the cymcuelftool to fill in all of the dfu/crc sections that are included in the code. But the options it uses fails to fill in the signature (a.k.a. the 32 bit CRC of the code image) the cy_app_signature section:

ELF section .cy_app_signature found, but no hash specified. Skipping application signature

But... even if this had worked, it would not have been the final solution because where it only performed on the image fore the m4 core and not both the M0 and M4 cores (we want to verify both).

The previously mentioned signing step produces a "_signed.elf" version of the merged images and a ".hex" version of the merged images. If you try debugging at this point, Psoc Creator downloads the ".hex" version of the (incompletely signed) image of the code and the signature will still be 0x00000000.

So... to fix that, the big secret trick is to add the following to post_build_core1.bat file:

"C:\Program Files (x86)\Cypress\PDL\3.1.2\tools\win\elf\cymcuelftool.exe"

--sign %OUTPUT_DIR%\%PRJ_NAME%%ELF_EXT% CRC --hex %OUTPUT_DIR%\%PRJ_NAME%.hex

This repeats the signing process, but this time the CRC option is included and the signing process will succeed. It also clobbers the .hex file produced by Psoc Creator and replaces it with one that actually contains the signature.

There is one other "gotcha" to watch out for. The space allocated if flash for the core0 and core1 parts of the code have to be contiguous and completely fill the two regions:

    flash_app0_core0  (rx)  : ORIGIN = 0x10000000, LENGTH = 0x30000

    flash_app0_core1  (rx)  : ORIGIN = 0x10030000, LENGTH = 0x30000

If you used

    flash_app0_core0  (rx)  : ORIGIN = 0x10000000, LENGTH = 0x10000

    flash_app0_core1  (rx)  : ORIGIN = 0x10030000, LENGTH = 0x30000

the CRC will probably not be correct.