Hi Alamy, I'm not sure I triggered the same issue as you did but I got the same error log. According to my debugging result, the regression was stuck because the tfm_sst_init() failed. As a result, signal value kept as 0x0 since it was not modified by any event. It means that signal == 0x0 is result of SST initialization failure, instead of the cause of abort as we previously met.

I'd like to suggest to keep TFM_RAM_FS enabled in current regression test until the Flash integration is fully completed yet. AFAIK, the system call from CM0+ or CM4 to request ROM code to execute Flash operation is not implemented yet.
However, if it is proved to be a issue of TF-M SST implementation, please help post the details in TF-M mailing list.

Hi David,

My case is triggered in the main while loop in tfm_sst_req_mgt_init().
If you are sure about that TF-M SST implementation is not completed yet, I'll keep TFM_RAM_FS enabled at the current stage.

One of my other tests is as below for your info.
The SST 1001 test case does the following thing:

1. psa_ps_set() # 1st set
2. psa_ps_set() # 2nd time
3. psa_ps_set(INVALID_UID) # should fail
4. psa_ps_remove()

If I disable step 2 & 3, the test will pass when TFM_RAM_FS is disabled (using Flash Driver)

Hi Alamy,

The SST implementations are completed. The key point is whether the PSoC 6 Flash operations can co-work with SST implementation.
As shown in the error log, the CM4 hasn't been activated when the issues occurs (no matter it occurs during init or in while (1) loop). Thus in theory, multi-core functionalities are not enabled yet at that moment. The secure part on CM0+ actually runs in the exactly the same way as it does in single Armv8-M. I would prefer to consider it as an issue between SST and Flash operation, rather than an unknown issue hiding deeply in TF-M SPM,
From the DS-5 screenshot attached, I cannot tell on which instruction the abort is triggered. Please add explicit error dumps before both tfm_abort() in init and while loop.

I also met a lot of errors in SST test cases when booting succeeds with SST_RAM_FS disabled. It also indicates that SST and PSoC 6 Flash driver may not work perfectly. It may be because SST implementation doesn't fit some Flash features on PSoC 6, or because PSoC 6 Flash driver doesn't behavior as SST expects.
I'd like to suggest to locate the errors failing the test cases, instead of hacking SST test cases. It may be the same root cause blocking the SST init.

Besides, it is a very interesting fact that, on my PSoC 6 with SST_RAM_FS disabled, the first execution after flash programming will always succeed with SST test errors. But all the following executions after reset always fail and are stuck in tfm_sst_init(), until the PSoC 6 board is re-programmed. Some data stored in Flash may be in a clean status in first execution but may not work normally then.

Thank a lot for the detail analyzation.
The ticket should belong to Andrei then :)
I'll discuss this with him when he is back next week.

Patch https://review.trustedfirmware.org/c/trusted-firmware-m/+/1588 from Alamy can fix the failure in tfm_sst_init() and some SST test cases.
Some regression SST test cases still fail. Need further debugging.

DO NOT click the link posted by ericjonze.
It is a malicious link.

I disabled user ericjonz and deleted his malicious comment. Thanks for bringing to our attention David
don

I often watch them to learn something, and then I play 1v1.lol unblocked, which is a very interesting survival shooting game

To be sure there are no unexpected alterations creating this problem, examine the changes ovo game made in the commits you provided. Pay particular attention to the adjustments made to disable SST_RAM_FS and handle Flash memory.