SRAM2 Differences Between L433 & L452?

Rob.Riggs · ‎2017-06-06

Posted on June 07, 2017 at 05:11

I have been fighting with a problem for the past few days as I port a board over from an STM32L433CC to an STM32L452CE. Code that runs fine on the L433CC causes a hard fault on the L452CE. After quite a bit of effort, I narrowed the problem down to code and data that I have in SRAM2. This fits in 16KB on the L433CC and works fine on that chip. Simply adding the code in blue is enough to make the part trigger a usage fault with an INVALID STATE sometime within 10-300 seconds of running.

void arm_fir_f32(

const arm_fir_instance_f32 * S,

float32_t * pSrc,

float32_t * pDst,

uint32_t blockSize)

__attribute__((section('.bss2')));

With the code running from either FLASH or from SRAM1, it works fine.

This would be acceptable if it failed immediately because my linker script was wrong or my startup code was not initializing SRAM2 properly. But that's not the case. The code works fine for a while, churning through many blocks of data. I have looked through the reference manual for both parts and I don't see any issues with the way I am using SRAM2.

While the FIR filter is executing in SRAM2 (against data held in SRAM1) there is data being moved from ADC1 to a circular buffer in SRAM1 via DMA (DMA 1, Channel 1), clocked by TIM6 at 26400 sps.

The SysClk is 80MHz via a 16MHz HSE.

I'm going to try to narrow this down to a very simple test case. In the meantime, is there anything I should look at with my usage of SRAM2 on the STM32L452CE?

Rob

#sram2 #stm32l452 #usage-fault #invalid-state

Viktor POHORELY · ‎2017-06-07

Posted on June 07, 2017 at 11:53

There is no difference on SRAM2 between L43x / L45x, except the obvious once related to different size of the SRAM1/SRAM2.

Rob.Riggs · ‎2017-06-09

Posted on June 10, 2017 at 05:29

pohorely.viktor

‌

Thank you for your response. I'm not much further into discovering why I am experiencing these problems, but I have a couple of new data points which may help shed some light on the issue.

I tried enabling parity check on SRAM2, using the MPU to restrict SRAM2 to read/exec only (AN4838) and enabling SRAM2 write protection. This had no impact on the problem. It does not appear to be due to corruption of the memory.

The problem seems to disappear if I define SRAM2 as starting at 0x20020000 instead of 0x10000000.

This fails:

RAM1 (rw) : ORIGIN = 0x20000000, LENGTH = 128K

RAM2 (xrw) : ORIGIN = 0x10000000, LENGTH = 32K

FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 512K

This works:

RAM1 (rw) : ORIGIN = 0x20000000, LENGTH = 128K

RAM2 (xrw) : ORIGIN = 0x20020000, LENGTH = 32K

FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 512K

However, with the working version performance is negatively impacted. It's about 25% slower with the second versionthan when running from the 0x10000000 region.

I have yet to find any documentation that indicates this performance difference is expected behavior.

waclawek.jan · ‎2017-06-11

Posted on June 11, 2017 at 16:12

I'd try to review the power and ground connections. Is it the same board as was with the 'L433?

I have yet to find any documentation that indicates this performance difference is expected behavior.

There might be increased fight for the processor's S-bus. I also faintly remember that the S-bus is registered when read, which means 1 cycle penalty compared to the D/I buses.

Only marginally related: Fig.1 in RM0394 and the narrative in ch.2.1.3 indicate, that SRAM2 is not accessible through S-bus, thus it shouldn't be available at the 0x2xxxxxxx address... which apparently is not the case.

JW

waclawek.jan · ‎2017-06-11

Posted on June 11, 2017 at 16:42

I also faintly remember that the S-bus is registered when read, which means 1 cycle penalty compared to the D/I buses.

Which also reminds me to nag again:

ST, please renew the

https://community.st.com/0D50X00009Xkba4SAB

JW

Rob.Riggs · ‎2017-06-21

Posted on June 22, 2017 at 04:33

It has been a bit since I could come back to this. I moved all of the code out of SRAM2 and have been running usage tests and measuring power consumption. It is running non-stop for the past week from Flash, using SRAM2 for data only.

The board I am testing the 452 on is a newer rev with improved grounding and less noise on VDDA. The power and ground connections are OK on both boards. To verify that this was not a PCB issue I assembled the same new PCB with a 433 so I could compare the two on the exact same board. I had changed the code earlier so that the same code would run on both. I change only the linker script, the startup assembly, and the CPU macro (-DSTM32L433xx or -DSTM32L542xx). I use only peripherals and timers common to the two.

With identical boards the 433 works perfectly fine running code from SRAM2 and the 452 faults.

I tried to replicate the issue using a pared-down test case on a 452 Nucleo board with no luck. It's a different chip (a 64-pin RE variant) and I was running different code.

waclawek.jan · ‎2017-06-22

Posted on June 22, 2017 at 08:48

I'm going to try to narrow this down to a very simple test case.

Please do.

JW

Rob.Riggs · ‎2017-06-23

Posted on June 24, 2017 at 05:26

A simple test case is now available here.

https://github.com/mobilinkd/nucleo-l452-sram2-fault

This test case is on an STM32L452RE Nucleo-64 board.

Rob.Riggs · ‎2017-06-26

Posted on June 26, 2017 at 14:39

Hi

pohorely.viktor

‌,

I have posted example code that replicates the issue on a reference platform (STM33L452RE Nucleo board) along with similar code for the STM32L432KC Nucleo board which works as expected. Please let me know if there is anything else I can provide to help identify the issue.

The code is linked from my previous post.

Thanks,

Rob