2019-01-16 03:04 AM
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:
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:
Thank you,
rvan
2019-04-19 08:40 AM
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
2019-09-17 03:45 PM
Hi Jocelyn,
We're having the same issue with SBSFU on the STM32L4R7. Has a workaround been identified for this problem yet?
Thanks,
Alex
2019-10-04 11:11 AM
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
2019-10-09 08:14 AM
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