H7 SBSFU DTCM usage

[David Littell]

Hi All,

Does the SBSFU reserve all of the DTCM in an H7 (stored state information, etc., expected to be stable across Core resets) such that the application shouldn't touch any of it after beginning execution?  The "Protected RAM ..." note in AN5056 Figure 12 implies this, or am I reading it wrong?

Thanks!

[Bubbles]

Hi @David Littell,

let me assume you are referring to the STM32H7B3 SBSFU (there is also one for H750 and some for H753).

The figure 12 is about the STM32L4, but looking at the mapping_sbsfu.icf file I can see that the DTCM is completely reserved by the SE and SB, yes.

But in the map file, most of that memory space is listed as unused. I think you can try reducing this allocation and use some of DTCM for the application. Just make sure to test that modification and also check the MPU settings.

BR,

J

[Bubbles · Accepted solution]

Hi, I checked with the SBSFU developers and they explained the situation. DTCM memory is considered very secure (no DMA access), so the SB is using it a lot. But after boot most of that memory is released for the application to use:

	Size (bytes)	Role (boot time)	Role (run time)
0x20000000 0x20000FFF	4096	Secure Engine's private stack	Secure Engine's private stack
0x20001000 0x200010FF	256	Secure memory activation code area (Reused)	User application RAM (126 960 bytes = 123.98 kB)
0x20001100 0x2001FFEF	126 704	SBSFU RAM (Reused)
0x2001FFF0 0x2001FFFF	16	Shared RAM for Image State Handling	Shared RAM for Image State Handling

Does that answer your question?

BR,

J

[David Littell]

Yes, I believe this does clarify things.  It'd probably be helpful for this kind of information to be include in the AN's.

Thanks,

Dave

[David Littell]

It would've been helpful if those tiny 256- and 16-byte areas ("Secure memory activation code" and "Shared RAM for Image State Handling") had been tucked away at the top of the 4KB Secure Engine's (huge) private stack. That way everything after 0x20001000 would be usable by the application SW.