Strange STM32L152CBT6 Hard Fault issues

[dadman]

Posted on January 21, 2014 at 22:43

Hi all, 

I''ve spent three strange nights of trying to find solution for the following issue.

No success yet.

I'll be very glad for any advice how to solve it.

I've designed a board with STM32L152CBT6 (48pins)

Low power MCU 128kb Flash, 16kb RAM 

Running on 32Mhz HSI

gcc 4.7.2 CodeSourcery, C/C++ with stdlib.

Stack size 0x400

The board contains just the MCU, SWD pins for Segger JLink connection for debugging and CC11001 RF 868Mhz module from Alibaba attached via 2mm spacing header and LED.

The power source is 1A DCDC converter TracoPower 3,3V.

The MCU has proper blocking capacitors 100nf (+1uF for VDDA).

The MCU uses SPI2 (PB12 CS, PB13 CLK, PB14 MISO, PB15 MOSI) and PB5 for IRQ handler EXTI_Line5.

I'm running my RF packet library for the Radio as a test case.

At first I need to mention that the same library/test I'm running without any issue on STMF4 Discovery Kit, self-designed board with STM32F103VC and as well on STM32L152 Discovery board. 

The last STM32L152RBT6 MCU is almost the same MCU with the same memory configuration, just with 64 pins.

So what is the issue:

The issue is Hard Faults during execution. The Hard Fault occurrence is irregular but typically it happens when a packet is sent via RF. Sometimes this is the first packet sometimes it is running stable but when i touch a board the Hard fault occurres. The packet send consumes up to 30mA current.

After three days of testing I have found a workaround how deal with.

It is enough just to put this code during board initialization

        GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT;

GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;

GPIO_InitStructure.GPIO_PuPd  = GPIO_PuPd_NOPULL;

GPIO_InitStructure.GPIO_Speed = GPIO_Speed_40MHz;

GPIO_InitStructure.GPIO_Pin =  GPIO_Pin_6;

GPIO_Init(GPIOB, &GPIO_InitStructure);

The code only initializes the pin PB6 as output on already running GPIOB clock.

That's enough. No setting on/off the pin is needed and the board immediately running perfectly stable like on other boards I've mentioned before.

The PB6 is connected via  SMD LED a resistor 750R to ground.

The voltage on the pin is at about 5mV.

When I've tried to remove the LED from board the Hard Fault returned back immediately.

I've tried to build another copy of the board to eliminate the MCU problem, the PCB problem, soldering problem etc.

And the result? The second board has the same strange problem.

Thank you very  much for your advice

Regards

Jakub

#stm-forum-software-pisses-me-off #stm32-hard-fault

[dadman]

Posted on January 24, 2014 at 13:57

Today I've tried to more stabilize the hardware used. 

I have found a solution for stabilizing the MCU without need to initialize PB6.The solution is to put Ferrite Bead (Murata 

BLM18BD152SN1D) on VDD route to the CC1101.

Before that I have tried to measure some spikes on VDD, communication lines, IRQ lines but without any finding. All looked well. So I dont exactly know how really the bead helped :-(.

[Tesla DeLorean]

Posted on January 24, 2014 at 16:01

Does the EXTI pin float?

The extra bit is troubling, I guess you'd want to suspect speed/voltage and prefetch. The prefetch path is one of the critical ones, and low voltages will slow things down, including the flash. Do you have some bulk capacitance close into the supply pins, along with the decoupling caps? This is from the L1-DISCO, C19 is not a tant, and I might look to get a 1uF or 2.2uF close in on the VDD side, especially if the RF TX pulls a lot of instantaneous current, and you'd want it on the chip side of the inductor/choke

[dadman]

Posted on January 24, 2014 at 16:41

> Does the EXTI pin float?

The EXTI Pin settings on my side: GPIO_InitStructure.GPIO_Pin =  GPIO_Pin_GD0 ; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IN; GPIO_InitStructure.GPIO_OType = GPIO_OType_PP; GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_DOWN; GPIO_Init(GDO_GPIO_PORT, &GPIO_InitStructure);From the Voltage point of view on my scope the EXTI pin is stable at LOW or High, driven by CC1101. No external pullup or pull down resistor.>The extra bit is troubling, I guess you'd want to suspect speed/voltage and prefetch. The prefetch path is one of the critical ones, and low voltages will slow things down, including the flash.> Do you have some bulk capacitance close into the supply pins, along with the decoupling caps? This is from the L1-DISCO, C19 is not a tant, and I might look to get a 1uF or 2.2uF close in on the VDD side, especially if the RF TX pulls a lot of instantaneous current, and you'd want it on the chip side of the inductor/chokeThis is my pcb with capacitances. This is done based on recommendations from STM32L152 Disovery kit (almost the same like your schematic). No bulk capacitance near of VDD pins. I have tried to add 1uF to C12 in parallel with no success. The 10uF tantalum is one inch far from MCU near to LDO. No chokes.Don't look at the MCU name on schmatic STM32L152CBT6 is used

[Tesla DeLorean]

Posted on January 24, 2014 at 16:59

Do you have an LCD? Is there connectivity here? Illustrated in PURPLE

Or any other bulk cap on the VDD side? You mentioned the one on the supply, but that's presumably there for the regulator, and on current path shared with the RF module. Edit: Never mind is see the net attached to VDDA, but not sure you want to connect the nets like that, as all the digital noise routes through the VDDA pin to get to it's charge storage.

[dadman]

Posted on January 24, 2014 at 17:14

>Do you have an LCD? Is there connectivity here? Illustrated in PURPLE

I have no LCD. I have  no the puple connection in my design. But I've tried to connect it by wire + add 1uF directly parallel with C12. >Or any other bulk cap on the VDD side? You mentioned the one on the supply, but that's presumably there for the regulator, and on current path shared with the RF module.No other cap except the shared LDO 10uF. (but I've tried the 1uF as mentioned before)> Edit: Never mind is see the net attached to VDDA, but not sure you want to connect the nets like that, as all the digital noise routes through the VDDA pin to get to it's charge storage. I'm not using ADC but I will change it. I including the more from the PCB layout to see the overall layout.

[dadman]

Posted on January 24, 2014 at 17:16

The Ferrite beads that help mi solve the problem are near to symbol X3 on VDD path to RF module and near to pin PB5.

[dadman]

Posted on January 25, 2014 at 14:06

Next findings:

I've spent hours finding some configuration of capacitors to solve the problem. No success :-(.I've unsoldered and measured capacitance of VDD-GND capacitor on RF module -> 5uF. I found that on the RF module is already placed ferrite bead on VDD path.I've tried add capacitors form 1uF to 4.7uF near to MCU on different places with different combinations. No luck at all.The only way I've found to solve the issue is to add Ferrite bead on VDD path to RF module and  on IRQ path from RF module.But still, in every HW configruation is sufficent to init GPIO pin PB6 and everything works perfectly stable.I will probably give up to find the real cause and use the PB6 workaround and ferrite beads.Many thanks to all for advices, namely to Clive1. One question on Clive: Do I need to connect VDD to VLCD pin  if I have no LCD connected? Or it is ok to leave the VLCD pin connected to GND via 1uF capacitor (as on the PCB design  posted) ?

[Tesla DeLorean]

Posted on January 25, 2014 at 15:05

You might want to look if you can use PB5 as a timer input, I suspect the EXTI rising/falling is very sensitive to glitches, the TIM input capture should at least permit some filtering. In EXTI mode you could also toggle a GPIO and see if the scope suggests and rapid pulses, or need for debouncing.

You are correct the L152 doesn't need a supply on VLCD, the L151 expects VDD. The L1-DISCO provides a way of bridging, but that looks to be unpopulated. I'm guessing this is a 2-layer board, with grounding on the back, or perhaps 4-layer. I probably would have done a couple of things a bit different. I'd have a top layer ground immediately under the RF module, and not route signals directly under the module. For the 2-layer putting the signal routing on the back, and pulling the routing closer to the pin connector end, away from the antenna, and active portion of the TX circuits/amps. I would have bifurcated the 3V at C25, taking the RF module supply around the right side, and the supply to the STM32 from the left. I would have widened the trace width for the supply under the STM32, and to circuitry beyond it, and reconfigure the VDDA flow wrt to the bulk/decoupling. For 2-layer board power routing tends to be a problem, I tend to think of it like plumbing, the pipes need to be thick by the supply, tapering to the end-points

[dadman]

Posted on January 25, 2014 at 16:47

I have changed GPIO pin for the EXTI IRQ handler from PB5 to PA2 and everything works perfectly. Voodoo.

[dadman]

Posted on January 25, 2014 at 23:02

>I'm guessing this is a 2-layer board, with grounding on the back, or perhaps 4-layer.

2 layer board>I probably would have done a couple of things a bit different.>I'd have a top layer ground immediately under the RF module, and not route signals directly under the module. DONE>For the 2-layer putting the signal routing on the back, and pulling the routing closer to the pin connector end, away from the antenna, and active portion of the TX circuits/amps.DONE>I would have bifurcated the 3V at C25, taking the RF module supply around the right side, and the supply to the STM32 from the left.DONE>I would have widened the trace width for the supply under the STM32, and to circuitry beyond it, and reconfigure the VDDA flow wrt to the bulk/decoupling.DONE>For 2-layer board power routing tends to be a problem, I tend to think of it like plumbing, the pipes need to be thick by the supply, tapering to the end-pointsI've added two ferrite beads for RF VDD and IRQ line as well.I've routed the IRQ to PA1I've added C6 2u2 for VDD route near to VDD.I''ve also removed the crystal because I will run it on HSI.I HOPE the new PCB will be stable and running well :-).Thank you very much for your time and advice.