Board reboots when a function is executed in TF-M

[Pablosanserr]

Hi,

I'm moving a project from SPM to TF-M. I have imported a static library and the board (nRF5340DK) restarts automatically every time the following mycli/main.c function is executed: signature.

signature(pk, msg, buffer);

More specifically, the problem occurs when executing blst_sign_pk_in_g1 function, which is located in lib/bls_hsm.h.

blst_sign_pk_in_g1(&sig, &hash, secret_keys_store + pk_index*sizeof(blst_scalar));

Other functions from the static library are executed correctly, so I guess the problem is not in the import of the library, but must be related to memory. In case it is of any interest, a few weeks ago I had problems importing such a static library into TF-M. The problem was solved as indicated in the following forum ticket: Problem importing a library into TF-M: Not enough space to import i.

I attach a link to the github project repo, so that the error can be easily reproduced: bls-hsm-2. To reproduce the error, build and execute application mycli. You will see that the board reboots.

Thank you in advice,

Pablo

Useful information about the project:
- I'm using the nRF5340DK development kit.
- nRF SDK v2.0.0
- The project is based on the example: TF-M Secure Partition Sample. When doing the build for this example, the available and used space shown is as follows:

[dejans]

Hi,

I have reproduced your issue. I'll look into it more tomorrow.

Best regards,
Dejan

[dejans]

Hi,

When doing the build for this example, the available and used space shown is as follows:

I guess something is missing. I don't see anything after "follows:". Could you please resend what you wanted to send initially?

Best regards,
Dejan

[dejans]

Hi,

I have tested your sample from non_secure branch and it was successful. I also tested your sample from the main branch and it still gives many warnings during the build process. Could you please remove the warnings from main branch?

TF-M uses 2 UART interfaces for logging, one for secure part (TF-M and MCUboot) and one for the application. Documentation provides more information about logging. With regard to secure logging, you can refer to the TF-M logging section.
Could you send both application and TF-M output logs with and without "Enable debug options"?

Best regards,
Dejan

[Pablosanserr]

Hi,

I have removed the warnings that appeared when making the build. The problem has not been solved.

I have made a build with and without the "Enable debug option" and another one with it enabled. In order to enable the "Enable debug options" option, I had to increase the TF-M size. It is 0x50000 without enabling the option and 0x60000 by enabling the option. This can be checked in the prj.conf file.

Again, I show what you get when you run the following command

west build -t partition_manager_report

Build without debug options enabled:

Build with debug options enabled:

It is not clear to me which logs you need, so I would be grateful if you could specify which ones you need if they are not the ones I have given you.

Regards,
Pablo

[dejans]

Hi Pablo,

The first log is ordinary UART application log. If UART logging is enabled in your application, you could use any terminal emulation program to see the log as shown in testing and debugging application. To see application log, you would need to connect to COM port corresponding to the application (VCOM1 in VS Code).

As mentioned before, documentation explains TF-M logging. I'll provide more details here. If you want to see TF-M log, you would need to take log from UART1. If you have 2 nRF5340-DKs (v2.0.0), you could connect them together to get required logs. First, flash the project to the first DK (DK-A) and recover the second board (DK-B). Connect pins P0.25 and P0.26 on DK-A to pins P1.00 (RXD) and P1.01 (TXD) on DK-B. Using terminal emulation program, connect to the COM ports on both devices. One of the COM ports (VCOM1 in VS Code) on the DK-A will show the application log and one of the COM ports (VCOM0 in VS Code) on DK-B will show the TF-M log.

In case that you have only one nRF5340-DK board, you could connect USB to serial converter cable directly to the DK-A using pins P0.25 and P0.26. You would then have 2 COM ports and 1 USB port open. You could then connect to the second VCOM port (VCOM1) shown in VS Code to see application log and to the COM port which corresponds to UART Serial port to see TF-M log.

Best regards,
Dejan

[Pablosanserr]

Hi Dejans,

I have connected pins P0.25 and P0.26 to a USB-to-serial converter and managed to get the TF-M log. Here are the logs obtained from TF-M and the application output:

Without "enable debug options"

Application output

TF-M log

With "enable debug options"

Application output

TF-M log

It seems to be no difference whether the "enable debug configuration" option is enabled or not. I would like to remind you that the board restarts automatically when the error occurs. This is the reason why you see the same thing 3 times in each log image.

I have not been able to observe any log of the application, from the non-secure partition. My understanding was that I should see it in VCOM1 in VS Code. I have also tried using PuTTY, and got nothing. I also tried with VCOM0, but nothing happened. VCOM2 is the application output.

I thought that, maybe, there was nothing to show this log. Therefore, I tried adding the following configuration:

CONFIG_LOG_PRINTK=y

This should dump the printk messages from my code to the log. However, I still couldn't manage to see those messages in the log.

Note: I get the TF-M log output from a linux virtual machine, as I was having problems with my USB-to-serial converter drivers. So I tried to look at the application's log from there, but I didn't get any result either.

I will keep trying to get the application log. If I succeed, I will post it on the forum. Meanwhile, this is all I have.

Regards,
Pablo

[dejans]

Hi Pablo,

Thank you for the logs. I have tested your sample (from main) using NCS v2.0.0, nRF5340-DK and Windows 10, but I could not reproduce your issue. I didn't get any board resets. You could try using system without virtual machine.

Best regards,
Dejan

[Pablosanserr]

Hi Dejans,

It is normal that you could not reproduce the error. In one of the last commits, by mistake, I commented the program line that caused the board to reboot.

In order to reproduce the error, lines 53 and 54 (shown below), must not be commented. This allows you to reproduce the error, which you were able to test at the time.

char msg[] = "5656565656565656565656565656565656565656565656565656565656565656";
signature(pk, msg, buffer);	

This change must be made in the mycli/src/main.c file. You can try to remove the comment to those two lines and launch the application. As soon as I can, I will put it back in the repository, so you can reproduce the error directly.

I also use my computer with Windows 10. The use of the virtual machine was for the purpose of obtaining the TF-M logs.

Best regards,
Pablo

[Pablosanserr]

Hi again, Dejans,

As you can see in the repo, I have put back the function that causes the reboot, so you can reproduce the error again.

Also, I've added a function to give me an idea of how much space is available in memory. It is not the most accurate method to obtain the available memory, but it is useful to get an estimate.

static uint32_t GetFreeMemorySize()
{
  uint32_t  i;
  uint32_t  len;
  uint8_t*  ptr;
 
  for(i=1;;i++)
  {
    len = i * 1024;
    ptr = (uint8_t*)malloc(len);
    if(!ptr){
      break;
    }
    free(ptr);
  }
 
  return i;
}

I execute this function just before the signature, the function that causes the reboot. This is what I get at the output, doing a debug with the "Enable debug options" option enabled:

I thought it would be a good idea to compare it with the result of the original project, bls-hsm, which uses SPM for secure-partition and NCS 1.8.0. This is what I get at the output, doing a debug with the "Enable debug options" option enabled:

The difference in available space is significant: it is approximately 5.6 times larger for the original version, using SPM (NCS 1.8.0), compared to the new version, using TF-M (NCS 2.0.0).

I don't know if the error might be related to that, but I thought this might be of interest.

Best regards,
Pablo

[dejans]

Hi Pablo,

I have tested again with the same setup using your main branch (with 2 lines that you mentioned uncommented) and got the same result as before. I could not observe board resets.

Best regards,
Dejan

[Pablosanserr]

Hi Dejans,

I have updated the repo. Can you clone the repo again, do the build and launch the application please? I just tried cloning it and I can reproduce the problem, as you can see below (it restarts the application).

Regards,
Pablo

[dejans]

Hi Pablo,

I have reproduced your board resetting issue. Using the same approach as have been suggested to you in your other case, I have got FATAL ERROR: UsageFault. It seems that the problem occurs when jumping to non-secure code with jump_to_ns_code(). I have reported the issue internally. 

Best regards,
Dejan