Firewall reset when accessing unprotected SRAM1 memory, STM32L4R9

[rvan]

Hello, I've adapted SBSFU (X-CUBE-SBSFU) example projects for a STM32L4R9 ​in single bank (flash) mode. I get a firewall reset when accessing SRAM1 that's outside of the defined protected area. Only a small section of SRAM1 is protected by the SBSFU (the secure engine itself, about 4k), so I'm losing quite alot of usable SRAM. According to the STM32L4R errata (en.DM00371862) there are 2 Firewall related limitations:

1. Only 128kB of the 192kB can be protected by the firewall.
2. A 'Spurious' Firewall reset can occur when using FMC or OctoSPI.

I'm not using FMC or OctoSPI; I am using LTDC, SDMMC and UARTs.

Even when accesing SRAM1 above 128kB (which can't be protected) I get Firewall resets.

Using SRAM2 and SRAM3 is ok; no problems there...

So following questions:

1. Is the 'spurious' firewall reset possible on SRAM1 above 128kB?
2. Can it be caused by peripherals other dan OctoSPI and FMC?
3. Am I missing something? Any other suggestions?

Thank you,

rvan

[Jocelyn RICARD]

Hello Rvan,

This is not the first time I see this issue. I suspect another problem in the firewall of the L4+ family not mentionned in the errata.

I raised this issue internally. I will come back to you when I have more details and if a workaround is possible.

Best regards

Jocelyn

[ahliao24]

Hi Jocelyn,

We're having the same issue with SBSFU on the STM32L4R7. Has a workaround been identified for this problem yet?

Thanks,

Alex

[Jocelyn RICARD]

Hello,

I'm sorry for big delay in answer. I had to ask and made some tests.

First, here is the description of the issue:

1/ A SRAM1 area is configured to be protected using Firewall in an specific address range

2/ Then a SRAM1 access occurs (whatever the SRAM1 address) because of data/stack/heap or whatever

3/ Then an access is done just after at an address with the 18 lsb bits exactly same as the ones configured in Firewall for SRAM1

 In this case a spurious Firewall Reset occurs

So, for instance, if you setup a firewall area of 4KB at beginning of SRAM1 that is from 0x20000000 to 0x20000FFF

Then one access to SRAM1 is done followed by one access in another SRAM with same low 18 bits:

For instance beginning of SRAM3 at any address between 0x20040000 to 0x20040FFF will generate a reset because low 18 bits are shared with firewall RAM addresses.

If you access to 0x20041000, no problem.

Issue comes back at address 0x20080000

So, to sum-up, with current SBSFU setup, you can use the following mapping

SRAM1 : 4KB Firewall 0x20000000 to 0x20000FFF

SRAM2 : from 0x20030000 to 0x2003FFFF (64KB)

SRAM3 : from 0x20041000 to 0x2007FFFF (252 KB)

    from 0x20081000 to 0x2009FFFF (128 KB)

If you need more space for the firewall you will have to adapt the 2 forbidden areas in SRAM3.

Last point, if you map the SBSFU STACK on SRAM2 something goes wrong, I don't know why. Maybe something related to the double mapping for SRAM2 on 0x10000000.

Using SRAM3 is OK. For user application I didn't see any restriction using SRAM2.

I hope this will help

Best regards

Jocelyn

[rvan]

Hello Jocelyn,

thanks for your answer and for figuring this out. We will include your findings in the next update of our firmware.

Thank you,

rvan