Hi Raymond,

The build command and the hex creation are correct.

Could you try to erase the entire eFlash before programming it?

It can be done with Keil MDK, or you can create a hex file with srec_cat which only contains 0xFF bytes and program that one to the board.

Let me know whether does it solved the issue.

Tamas From: Raymond Ngun Raymond.Ngun@cypress.com Sent: 05 October 2020 23:07 To: Tamas Ban Tamas.Ban@arm.com; tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: RE: Musca-B1 and new build system

Thanks Tamas.

Unfortunately, this did not work for me. Here is what I did to build. Let me know if I did something wrong.

cmake -DTFM_PLATFORM=musca_b1 -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Debug -DTEST_NS=ON -DTEST_S=ON ../ cmake --build . --target install srec_cat install/outputs/MUSCA_B1/bl2.bin -Binary -offset 0xA000000 install/outputs/MUSCA_B1/tfm_s_ns_signed.bin -Binary -offset 0xA020000 -o tfm.hex -Intel

The resultant output is the following.

Entering standby.. [INF] Starting bootloader [ERR] Error while initializing the security counter

Thank you,

Ray

From: Tamas Ban <Tamas.Ban@arm.commailto:Tamas.Ban@arm.com> Sent: Thursday, October 1, 2020 3:05 AM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org; Raymond Ngun <Raymond.Ngun@cypress.commailto:Raymond.Ngun@cypress.com> Cc: nd <nd@arm.commailto:nd@arm.com> Subject: RE: Musca-B1 and new build system

Hi Raymond,

Here is the proposed fix: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6028

Could you verify on your board? Pls use at build -DCMAKE_BUILD_TYPE=Debug for full logging in bootloader.

Tamas

From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M Sent: 01 October 2020 10:37 To: Raymond Ngun <Raymond.Ngun@cypress.commailto:Raymond.Ngun@cypress.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto:nd@arm.com> Subject: Re: [TF-M] Musca-B1 and new build system

Hi Raymond,

Thanks for reporting the issue!

The observed behaviour has two reason: - In the new build system the default CMAKE_BUILD_TYPE=Release. In this case the logging is disabled in MCUboot to get smaller binary. You can set manualy to Debug in the command line to enable logging from bootloader

* This commit 7d591a684b4abb0f61fbba8668dd6ea7b4b68698 introduced a crash in Musca S1/B1. Fix is ongoing.

Tamas

From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Raymond Ngun via TF-M Sent: 30 September 2020 17:44 To: David Hu via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Musca-B1 and new build system

Hi all,

I am attempting to build Musca-B1 with the latest in master but I'm not able to get it to run (nothing shows on the UART). At a minimum, the User Guide is out of date in terms of how the final hex is created. So, I have a couple questions.

1. Is the latest tested with Musca-B1? 2. Can I obtain some updated information on how to build and create an image for Musca-B1?

Thank you,

Ray

This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

Hi Raymond,

I propose the following way to debug:

* I will build and send you a Musca-B1 image based on current master (fc8d2f7 Build: Remove PSA arch tests patch) for testing on your board. * Please send me both of your images, and if you have the corresponding *.axf files, and if you know the commit-id when they were built. * I would like to test and debug in my environment. * By the way do you have a debugger? Can you identify actually what does return an error during security counter init?

BR, Tamas

From: Raymond Ngun Raymond.Ngun@cypress.com Sent: 06 October 2020 23:53 To: Tamas Ban Tamas.Ban@arm.com; tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: RE: Musca-B1 and new build system

Hi Tamas,

It didn't make a difference. I have an old muscb1 image around and that continues to work fine but the new images do not work.

I wrote 2MB of 0xFF btw.

Thanks,

Ray

From: Tamas Ban <Tamas.Ban@arm.commailto:Tamas.Ban@arm.com> Sent: Tuesday, October 6, 2020 8:40 AM To: Raymond Ngun <Raymond.Ngun@cypress.commailto:Raymond.Ngun@cypress.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto:nd@arm.com> Subject: RE: Musca-B1 and new build system

Hi Raymond,

The build command and the hex creation are correct.

Could you try to erase the entire eFlash before programming it?

It can be done with Keil MDK, or you can create a hex file with srec_cat which only contains 0xFF bytes and program that one to the board.

Let me know whether does it solved the issue.

Tamas From: Raymond Ngun <Raymond.Ngun@cypress.commailto:Raymond.Ngun@cypress.com> Sent: 05 October 2020 23:07 To: Tamas Ban <Tamas.Ban@arm.commailto:Tamas.Ban@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto:nd@arm.com> Subject: RE: Musca-B1 and new build system

Thanks Tamas.

Unfortunately, this did not work for me. Here is what I did to build. Let me know if I did something wrong.

cmake -DTFM_PLATFORM=musca_b1 -DCMAKE_TOOLCHAIN_FILE=../toolchain_GNUARM.cmake -DCMAKE_BUILD_TYPE=Debug -DTEST_NS=ON -DTEST_S=ON ../ cmake --build . --target install srec_cat install/outputs/MUSCA_B1/bl2.bin -Binary -offset 0xA000000 install/outputs/MUSCA_B1/tfm_s_ns_signed.bin -Binary -offset 0xA020000 -o tfm.hex -Intel

The resultant output is the following.

Entering standby.. [INF] Starting bootloader [ERR] Error while initializing the security counter

Thank you,

Ray

From: Tamas Ban <Tamas.Ban@arm.commailto:Tamas.Ban@arm.com> Sent: Thursday, October 1, 2020 3:05 AM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org; Raymond Ngun <Raymond.Ngun@cypress.commailto:Raymond.Ngun@cypress.com> Cc: nd <nd@arm.commailto:nd@arm.com> Subject: RE: Musca-B1 and new build system

Hi Raymond,

Here is the proposed fix: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6028

Could you verify on your board? Pls use at build -DCMAKE_BUILD_TYPE=Debug for full logging in bootloader.

Tamas

From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M Sent: 01 October 2020 10:37 To: Raymond Ngun <Raymond.Ngun@cypress.commailto:Raymond.Ngun@cypress.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto:nd@arm.com> Subject: Re: [TF-M] Musca-B1 and new build system

Hi Raymond,

Thanks for reporting the issue!

The observed behaviour has two reason: - In the new build system the default CMAKE_BUILD_TYPE=Release. In this case the logging is disabled in MCUboot to get smaller binary. You can set manualy to Debug in the command line to enable logging from bootloader

* This commit 7d591a684b4abb0f61fbba8668dd6ea7b4b68698 introduced a crash in Musca S1/B1. Fix is ongoing.

Tamas

From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Raymond Ngun via TF-M Sent: 30 September 2020 17:44 To: David Hu via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Musca-B1 and new build system

Hi all,

I am attempting to build Musca-B1 with the latest in master but I'm not able to get it to run (nothing shows on the UART). At a minimum, the User Guide is out of date in terms of how the final hex is created. So, I have a couple questions.

1. Is the latest tested with Musca-B1? 2. Can I obtain some updated information on how to build and create an image for Musca-B1?

Thank you,

Ray

This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.