Diagnose Locking Up Issue

[atomic]

Hi there! I come from the Microchip world and just started on the STM32F2 this week. I’m really enjoying Visual GDB. The integration is nice into Visual Studio, since I also spend a great deal of time in C++ and recently C#. It’s nice to spend my days in a familiar IDE 😀

I’m not certain if this is specifically a Visual GDB question, or perhaps someone has had similar experience. We have an STM32F2 clocked to 120mhz with a 25mhz crystal. I’m using the default oscillator settings in Visual GDB as they seem to match our oscillator settings.

Here are the list of peripherals on our dev pcb:
– LED w/ 340 ohm resistor: A5
– LED w/ 340 ohm resistor: A7
– Amplifier and Speaker: A4

void DelayMS(int val) {

for (int p = 0; p < val * 8000; p++)
asm("nop");
}

void SetIODirection(GPIO_TypeDef *bank, int16 port, GPIOMode_TypeDef direction) {

GPIO_InitTypeDef GPIO_InitStructure;

GPIO_InitStructure.GPIO_Pin = port;
GPIO_InitStructure.GPIO_Mode = direction;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;

GPIO_Init(bank, &GPIO_InitStructure);
}

void InitTimer() {

RCC_APB2PeriphClockCmd(RCC_APB2Periph_TIM1, ENABLE);

TIM_TimeBaseInitTypeDef timerInitStructure;
timerInitStructure.TIM_CounterMode = TIM_CounterMode_Up;
timerInitStructure.TIM_Period = 500;
timerInitStructure.TIM_Prescaler = 40000;
timerInitStructure.TIM_ClockDivision = TIM_CKD_DIV1;
timerInitStructure.TIM_RepetitionCounter = 0;
TIM_TimeBaseInit(TIM1, &timerInitStructure);

TIM_Cmd(TIM1, ENABLE);

TIM_ITConfig(TIM1, TIM_IT_Update, ENABLE);

NVIC_InitTypeDef nvicStructure;
nvicStructure.NVIC_IRQChannel = TIM1_UP_TIM10_IRQn;
nvicStructure.NVIC_IRQChannelPreemptionPriority = 0;
nvicStructure.NVIC_IRQChannelSubPriority = 1;
nvicStructure.NVIC_IRQChannelCmd = ENABLE;
NVIC_Init(&nvicStructure);
}

extern "C" void TIM1_UP_TIM10_IRQHandler() {

if (TIM_GetITStatus(TIM1, TIM_IT_Update) != RESET) {

TIM_ClearITPendingBit(TIM1, TIM_IT_Update);

GPIO_ToggleBits(GPIOC, GPIO_Pin_5);
}
}

void SetupIO() {

RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOA, ENABLE);
RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOB, ENABLE);
RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOC, ENABLE);
RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOD, ENABLE);
RCC_APB1PeriphClockCmd(RCC_APB1Periph_DAC, ENABLE);

// LED #1
SetIODirection(GPIOA, GPIO_Pin_5, GPIO_Mode_OUT);

// LED #2
SetIODirection(GPIOA, GPIO_Pin_7, GPIO_Mode_OUT);

// Speaker
SetIODirection(GPIOA, GPIO_Pin_4, GPIO_Mode_OUT);

DAC_InitTypeDef dacStruct;

dacStruct.DAC_Trigger = DAC_Trigger_None;
dacStruct.DAC_LFSRUnmask_TriangleAmplitude = DAC_TriangleAmplitude_4095;
dacStruct.DAC_OutputBuffer = DAC_OutputBuffer_Disable;
dacStruct.DAC_WaveGeneration = DAC_WaveGeneration_Triangle;

DAC_Init(DAC_Channel_1, &dacStruct);
}

int main() {

DelayMS(2000);

SetupIO();

InitTimer();

for (;;) {

GPIO_WriteBit(GPIOA, GPIO_Pin_7, Bit_SET);

DelayMS(1000);

GPIO_WriteBit(GPIOA, GPIO_Pin_7, Bit_RESET);

DelayMS(250);
}

That only flashes 1 of the LED's (A7). The A5 LED will not flash, sometimes it will. When it does, it's very weak. When it didn't flash, I of course thought it was the LED, but it is not faulty. I probed the A5 pin on the STM32 and it seems to only rise to 0.4 volts when the bit is set.

Also, the debugger and programmer seem to lock up and be unresponsive when the FOR loop in MAIN starts running. The only way to program the chip is to connect to it quickly within the first 2000 MS delay (Which is why it's there). Because the power on the pins seem to be so low.

1) Does having A4 being used by DAC with A5 powering an LED cause an issue with the DAC on? I am writing only to DAC_Align_8b_R with DAC_SetChannel1Data().

2) Does using the DAC Buffer Enabled driving an amplifier cause too low impedance and do you think the bank A is damaged?

3) Do you think this chip is damaged by running it at 120mhz with multiple LED's on 340ohm resistors? (Max current is 120mha for the chip and it takes something like 60mha to run at 120mhz HSE)

I'm just generally confused on how inconsistent the results are every time I power it up. If I comment out the TImer code, it seems to work great. Soon as the TImer is running, it locks up and prevents the programmer from connecting to it unless I connect within the first 2 seconds after power up. I do not have another chip to test with, although we did order some.

My concern is I fried the chip by having too many LED's and the amplifier while running at 120mhz HSE. Now I think the results I'm experiencing are bizarre due to it being blown inside. But realistically, is 2 LED's and 1 Audio Amp too much for this chip? I

[support]

Hi,

It’s hard to tell what exactly is the cause of your problem, without looking at a specific device/board. Here are some general pieces of advice on diagnosing this further:

1. On most devices GPIO pins are multiplexed with peripherals and you need to explicitly switch between the peripheral mode and the GPIO mode. Please ensure that the A5 LED is not configured as an output of some other module.
2. The low voltage output can be a result of the pin working as an input with an internal pull-up resistor enabled. Please recheck that the direction register stays in the OUT mode for that pin.
3. Does anything change if you disable interrupts? If yes, are you sure you are handling them correctly? Can you verify it in the debugger?
4. Can the GPIO/timer output pins accidentally short-circuit anything on your board?
5. Can the perceived 0.4V output actually be a result of rapidly alternating 0 and 1 values (if your timer ISR gets invoked too frequently).
6. Does switching the GPIO numbers (toggle A5 from the main() and A7 from timer) change anything?

[atomic]

Thanks for the reply. The chip eventually gave out. It appears we had a faulty chip! More stranger and stranger things were happening before it stopped responding at all.

We ordered new chips and put them on our dev boards – things are responding great now.

For a bit I was very confused! I was starting to think the chip was haunted…

[fakir]

@atomic, It’s a little confusing, my controller hasn’t gotten haunted till now, just kidding. There has to a logical explanation for this, it might be because of a faulty voltage converter which wasn’t able to supply proper power to the controller and with time, it got worse. Normally if a controller is faulty, it shows the signs at the very beginning, while being programmed. Your issue got worse with time which means that there was some other issue with the board, perhaps a faulty component drawing more current than specified and creating issues for the board.

pcb assembly

[Author]

Posts