STM32WB15CC allow CPU1 to access all resources

[ALest]

I am trying use the stm32wb15cc to run an application on CPU1, but with no application in CPU. I don't need the RF side at all and want to hold CPU2 in reset and allow CPU1 to access all the Flash and Ram.

However this does not seem possible as Option Bytes are set to reserve parts of the flash and RAM 2a and 2b, so I have limited access. Apparently these bits can only be reset by CPU2. I tried using the Cube Programmer, but it was not able to change these bytes.

Is it possible to clear these bytes in some manner? Or can ST provide a binary for CPU2 that removes the security or just reduces the RAM lock to just the last 1KB of each region?

[Remi QUINTIN]

To hold the M0+ core, you just have to comment the LL_PWR_EnableBootC2 function in the

HW_IPCC_Enable function in the hw_ipcc.c file.

If you really need more space in the SRAM, you can even prevent the configuration of the IPCC (Inter Processor Communication Chanel) structures.

Note that we never tested this as the chip is not meant for that purpose.

[ALest]

Hi Remi,

Thanks for the reply, I will give it a go. I doubt it will work though, as the the RAM is locked by the flash option bytes. The documentation states that this prevents CPU1 from accessing the RAM whether or not CPU2 is booted or held in reset. The only way to change this is to modify the option bytes, but only CPU2 can access them. Apparently only ST can provide binaries that can be loaded onto CPU2, so that is why I am reaching out to see if ST can provide a simple binary for CPU2 that modifies these option bytes. Please correct me if I have misunderstood any of the above.

I know the chip is not really meant for this purpose, but due to supply chain issues, this route was actually recommended to us by ST and we were led to believe that we would be able to use the full 48K of RAM. After buying 1000 parts, we find we can only use 22 K, so we would really appreciate some help with this.

Thanks,

Allan

[Remi QUINTIN]

If you do not need the RF part, you do not have to load any wireless stack. In that case only the few sectors above the 0xF4 sector from Flash memory remain locked for M0+ core.

If the wireless stack is not executed, then the few option bytes configuring the SRAM should not be set up. And so you should be able to access a wider part of the SRAM.

Unfortunately, we will never provide any specific SW other than the wireless stacks.

[ALest]

Hi Remi,

Ok, I haven't explicitly loaded any wireless stacks, but my option bytes are already set. I am using the Nucleo-64 devkit for the STM32WB15, so this was probably already done before I even fired it up. Once we get our first revision of actual HW and fit brand new chips, are you saying that the option bytes should be blank and I won't see this issue?

Thanks,

Allan

[Remi QUINTIN]

Ok you should perform a FW delete via the CubeProgrammer tool. In that case you should have the complete Flash memory available for your application for a WB15 device.

Now regarding the SRAM, I think you should have access to a big part of the 48KB.

Just be sure that the IPCC structures (data buffers, ...) are not created by your application as you dont need them.

Note that we never tested this use case.

Erase/Overwrite the complete SRAM with data like 0xCAFE at the time you are programming your application and then you can check if one task accessed the SRAM just before entering the while loop having a look at the content of the SRAM.

[ALest]

Hi Remi,

I commented out the line that enables CPU2 and used the debugger to confirm that the C2BOOT bit was not set.

I used the CubeProgrammer to do a full chip erase. I then filled SRAM1 with 0xCAFE and confirmed that I was able to read and write to this part of the SRAM.

I then used the tool to read out the values of SRAM 2a, but as expected, saw only 0x00 for the area secured by the option bytes. I attempted to fill this region with 0xCAFE, but the CubeProgrammer failed to write to the protected region. I first tried filling 0x2800 bytes (which is the unlocked size) and that succeeded. I then attempted to fill 0x3000, but that failed as it hit the protected area.

Regards,

Allan

[Remi QUINTIN]

In fact, the 2 option bytes defining the start address of the protected area for SRAM2a and SRAM2b are set by the wireless stack only. So, there is no way for any application on the M4 core to access/modify them.

The only way would be to get a piece of code that would set them to the top of the SRAM memory. But we do not have such code.

What you can do is to try many wireless stacks to see which one is setting the protected area the upper.

[ALest]

Hi Remi,

That was my understanding as well and the reason behind this post requesting FW. My backup plan was to try the different wireless stacks in the hope that each one only sets the protected area to only the size it requires, but I suspect they will all default to the same size.

I'll give them a go and report back.

Thanks,

Allan

[ALest]

Hi Remi,

I never got around to loading any of the RF stacks. I found this info about 'Safeboot' and tried both the FUS "FW Delete" and then tried to force the safeboot by writing the value 0x00008000 at the address 0x5800040C.

After I rebooted, the SRAM2a security was disabled and I was able to test access to the full range of SRAM2a. This unlocked 32 KB, combined with the 12 KB of SRAM1, gives me all the memory I need for now. SRAM2b was still locked, but it is small enough that I don't care about it.

 

 

I tested access by reading every location in the range and then writing the same value back again.

I am not sure which of the two steps did the actual unlocking, but it is the end result that counts!

Regards,

Allan