Microcontroller malfunctions!

[Mujtaba]

Posted on March 15, 2017 at 09:49

Dear friends,

I have designed a PCB board to communicate with Modbus devices. I've use STM32F103RBT6 mcu and ADM485JRZ for RS485 communication. I have not soldered any other parts of the pcb except the micro and ADM485 and its driving circuit and I feed 3.3v (just for mcu) and 5v (just for ADM485) externally and I pulled down the BOOT0 pin through a 10kohms resistor and used external 8MHz crystal with 22pF ceramic capacitors and I used 2 LEDs to show the communication status.(LED1=on & LED2=off means data is transmitting and LED1=off & LED2=on means data is receiving and when both LEDs are off means no data is transmitting nor receiving).

The micro works properly and communicate with a Modbus key for about 10 minutes for the first time when I switch the 3.3v power on and both LEDs toggle as they are programmed. But after that, this communication stops and both LEDs are on(while no such thing is programmed for LEDs). When I power off the 3.3v and wait some time and feed it back o the micro, it again works properly and no errors happen. But this time micro works properly about 2 or 3 minutes.

And I've done it several times and I've seen the more I wait, the more it works properly(but never worked more than 10 minutes.). 

Do you have any ideas why it's happening?

Any helps would be appreciated.

[Danish1]

Posted on March 15, 2017 at 10:25

The 'wait some time' symptom could suggest that the problem might be thermal.

It could be that you have a joint that is not properly soldered, and it makes when everything is cold but fails when things warm up.

It could also be that you don't have adequate heatsinking for one of your voltage-regulators; that overheats and shuts down.

The next issue, given that you don't have much of the board populated, is that you might not have adequate power-supply-decoupling capacitors for the stm32 to work reliably. You might be feeding the processor from an excellent and well-regulated power-source, but through centimetres of power leads (and all the associated inductance). You need ceramic decoupling capacitors right on each and every power pin of the processor to ensure reliable operation.

Having said that, the other huge unknown is the software you're running on the board. It could crash. Do you have handlers for things like hardfault situations?

Hope this helps,

Danish

[AvaTar]

Posted on March 15, 2017 at 10:27

Microcontroller malfunctions!

Very unlikely.

Consider your application 'malfunctions' instead.

Use the recommended techniques, either run you application in the debugger, or instrument your code with debug outputs, to check what happens.

But this time micro works properly about 2 or 3 minutes.

The standard guess for this kind of issue is either stack overflow or out-of-bound array access.

[Mujtaba]

Posted on March 15, 2017 at 19:53

Dear Danish,

you were right. The problem lied within the soldering of the power supply.

Thanks for your reply. It was really helpful.

Could you please give me some information about hardfault situations?

All the best,

Mujtaba

[Danish1]

Posted on March 16, 2017 at 11:50

Hard-fault is a state the arm processor that is at the heart of an stm32 microcontroller.

When the processor has an event (e.g. a routine interrupt, an illegal instruction code, an attempt to access non-existant memory) it jumps out of the normal flow of code to execute the appropriate event handler. Routine events such as interrupts generally do a tiny amount of processing and then return to the flow of code.

If there's a problem trying to get to the event handler (i.e. you haven't written a handler for that event, and you don't have a catch-all handler), it gets a 'double fault' or 'hard fault' and tries to execute the hard-fault handler. What you could do under those circumstances is have code that logs the processor registers etc (to whatever debugging facility you have attached, or something that is remembered over reset) so that you can try to diagnose how and eventually why the problem occurred. This can help track down why code stopped working (although it's not an easy path to follow).

[AvaTar]

Posted on March 16, 2017 at 12:04

The most common consequence of a stack overflow is a hardfault.