STM32F415RGT ART Accelerator

[Tobias Wedell]

Posted on January 08, 2018 at 14:32

Hello,

in your first project we use a STM32F415ZGT without any problems. Then we switch to the smaller version STM32F415RGT in a new design. With the same source code we got some times a hard fault when die MCU is booting up.

After two or three days of software and hardware bug finding and trying different versions of CubeMX and F4 firmware we find a solution to disable the Instruction Cache in CubeMX:

After that your simple LED blink code runs fine without any hard fault.

Errata sheet lists a bug in Revision ''A'' devices for the ART Accelerator:

ART Accelerator prefetch queue instruction is not supported

Description

The ART Accelerator prefetch queue instruction is not supported on revision A devices.

This limitation does not prevent the ART Accelerator from using the cache enable/disable

capability and the selection of the number of wait states according to the system frequency.

Workaround

   �

Revision A devices: none

   �

Revision Z and 1 devices: fixed.

We found out that your STM32F415RGT is at Revision ''2'' and that revision is not listed in fixed devices.

Is this bug still existing in Revision ''2'' devices? And when not: Do you have any solution to your problem?

Best regards

#vssa #gnd #ferrite-beads #vss

[Tesla DeLorean]

Posted on January 08, 2018 at 15:11

What does DBGMCU->IDCODE report?

What frequency and wait states are being used?

[Tobias Wedell]

Posted on January 08, 2018 at 15:42

IDCODE = 0x10076413

SYSCLCK = 168 MHzWS = 5 (6 CPU cycle)

[waclawek.jan]

Posted on January 08, 2018 at 16:23

Is the supply voltage 3.3V and is it stable and well-decoupled? What's the voltage on the two VCAP pins, are they properly connected? Is PWR_CR.VOS=1 all the time? Are all GND/VCC pins connected properly, including the analog ones and VBAT?

JW

[Tesla DeLorean]

Posted on January 08, 2018 at 16:29

Looks Ok, I disable prefetch on the 0x411 parts (0x20006411) as there is a critical path in the cache that doesn't work properly across voltage/temperature.

As Jan indicates the next place to look would be the VOS settings, and VCAP pins, making sure you have the right voltages there and adequate bulk capacitance.

[Tobias Wedell]

Posted on January 08, 2018 at 16:46

We have tested three different power supplies for 3.3V and they are stable and works well with ZGT designs.

This is your shematic:

The FBx parts are ferrit beads for decoupling, type: TDK MMZ2012R601AT000.

I will check VCAP, PWR_CR:VOS and post.

[Tesla DeLorean]

Posted on January 08, 2018 at 16:53

The core powers from the 1.25V rail, CMOS has aggressive current draw at clock edges. You typically want low ESR, larger physical size capacitors for the VCAP pins

[Tobias Wedell]

Posted on January 08, 2018 at 17:02

Now we are using ceramic capacitors with very low ESR same as in the ZGT desings.

We will try to place larger ones. Thank you.

[Tesla DeLorean]

Posted on January 08, 2018 at 17:10

I would lean toward 0603 size.

Are you using GCC? The issues observed with the problem F2/F4 parts tended to be triggered more frequently with GNU/GCC based chains. Can't say I've seen any reports on issues on parts currently being distributed.

The FLASH wait states can be increased, but that is not associated with the prefetch issue where the cache attempts to deliver data within the current cycle (ie 0 cycles, vs 1 cycle SRAM)

[waclawek.jan · Accepted solution]

Posted on January 08, 2018 at 17:16

I'm not sure I'd put beads between the grounds; but I'm sure if I'd do that I'd put the capacitors *after* the beads, directly onto the mcu VSS pins. Most of them at least; and certainly those on VCAP pins.

Can you please try bypassing those beads?