Hardware Problems
#1
Hello Forum,

we have Problems to get our Controller running.
After Power On the Buzzer beep´s a while.

Here are several Log after Power On.

Can somebody help us?

If you will call me try +49 170 8339732

vy 73 de DG3FCP, Christian

2013-01-01 00:00:40 0 | [Hard fault handler - all numbers in hex]
2013-01-01 00:00:40 0 | R0 = 20000140
2013-01-01 00:00:40 0 | R1 = 802b109
2013-01-01 00:00:40 0 | R2 = 802b11a
2013-01-01 00:00:40 0 | R3 = 21000000
2013-01-01 00:00:40 0 | R12 = 40020400
2013-01-01 00:00:40 0 | LR [R14] = 1000 subroutine call return address
2013-01-01 00:00:40 0 | PC [R15] = 20011fe4 program counter
2013-01-01 00:00:40 0 | PSR = 801f6e5
2013-01-01 00:00:40 0 | BFAR = e000ed38
2013-01-01 00:00:40 0 | CFSR = 40000
2013-01-01 00:00:40 0 | HFSR = 40000000
2013-01-01 00:00:40 0 | DFSR = 0
2013-01-01 00:00:40 0 | AFSR = 0
2013-01-01 00:00:40 0 | SCB_SHCSR = 0

2013-01-01 00:00:01 0 | [Hard fault handler - all numbers in hex]
2013-01-01 00:00:01 0 | R0 = 88000000
2013-01-01 00:00:01 0 | R1 = 88000000
2013-01-01 00:00:01 0 | R2 = 0
2013-01-01 00:00:01 0 | R3 = 44
2013-01-01 00:00:01 0 | R12 = 0
2013-01-01 00:00:01 0 | LR [R14] = 8025d95 subroutine call return address
2013-01-01 00:00:01 0 | PC [R15] = 8025c4e program counter
2013-01-01 00:00:01 0 | PSR = 81000000
2013-01-01 00:00:01 0 | BFAR = e000ed38
2013-01-01 00:00:01 0 | CFSR = 10000
2013-01-01 00:00:01 0 | HFSR = 40000000
2013-01-01 00:00:01 0 | DFSR = 0
2013-01-01 00:00:01 0 | AFSR = 0
2013-01-01 00:00:01 0 | SCB_SHCSR = 0

2013-01-01 00:00:01 0 | [Hard fault handler - all numbers in hex]
2013-01-01 00:00:01 0 | R0 = 88000000
2013-01-01 00:00:01 0 | R1 = 80e8
2013-01-01 00:00:01 0 | R2 = 58a0
2013-01-01 00:00:01 0 | R3 = 589f
2013-01-01 00:00:01 0 | R12 = 0
2013-01-01 00:00:01 0 | LR [R14] = ffffffe9 subroutine call return address
2013-01-01 00:00:01 0 | PC [R15] = ffe9dfb6 program counter
2013-01-01 00:00:01 0 | PSR = 20000045
2013-01-01 00:00:01 0 | BFAR = e000ed38
2013-01-01 00:00:01 0 | CFSR = 1
2013-01-01 00:00:01 0 | HFSR = 40000000
2013-01-01 00:00:01 0 | DFSR = 0
2013-01-01 00:00:01 0 | AFSR = 0
2013-01-01 00:00:01 0 | SCB_SHCSR = 0
Stations: 1146
Reply
#2
Tell me the firmware version, what you see on the LCD and which of the four user LEDs are on when the problem occurs. Some more lines before the log might help too.
Stations: 538, 672, 1534, 1555, 1696, 1712, 2034, 2219
Reply
#3
(2014-08-16, 14:52)Tobi Wrote: Tell me the firmware version, what you see on the LCD and which of the four user LEDs are on when the problem occurs. Some more lines before the log might help too.

Hello Tobi,

thanks for fast reply?

On The LCD are the same informations as in the LOG.

Tree LED´s are on : red, yelow, green
Blue is off.

Here the LOG.

Can i call you?

2000-01-01 00:00:00 0 | ================ Blitzortung STM32F4 Controller Board ================
2000-01-01 00:00:00 0 | Firmware Rev. 7.3b1 / Aug 9 2014 19:28:42 (Git 7.3b1-0-g8aa7462)
2000-01-01 00:00:00 0 | Hardware Rev. 10.4 (Id 2)
2000-01-01 00:00:00 0 | Reset condition: BOR=1 PIN=1 POR=1 SOFT=0 IWD=0 WWD=0 LPW=0
2000-01-01 00:00:00 0 | HCLK: 168MHz
2000-01-01 00:00:00 0 | PCLK1 (APB1): 42MHz
2000-01-01 00:00:00 0 | PCLK2 (APB2): 84MHz
2000-01-01 00:00:00 0 | SYSCLK: 168MHz
2000-01-01 00:00:00 0 | ======================================================================
2000-01-01 00:00:00 0 |
2000-01-01 00:00:00 0 |
2000-01-01 00:00:00 0 | === ADC Defaults ===
2000-01-01 00:00:00 0 | Resolution: 12bits
2000-01-01 00:00:00 0 | Divider: 2
2000-01-01 00:00:00 0 | Sample Cycles 1: 56
2000-01-01 00:00:00 0 | Sample Cycles 2: 28
2000-01-01 00:00:00 0 |
2000-01-01 00:00:00 0 |
2000-01-01 00:00:00 0 | === ADC Configuration ===
2000-01-01 00:00:00 0 | Resolution: 12bits
2013-01-01 00:00:00 0 | START: Loaded TOA-Lightning-ALERT settings.
2013-01-01 00:00:00 0 | START: Loaded ACTION settings.
2013-01-01 00:00:00 0 | START: Initialized WEBSERVER on port 80.
2013-01-01 00:00:00 0 |
2013-01-01 00:00:00 0 | === Init HTTP Remote CONFIG ===
2013-01-01 00:00:00 0 | REMOTE-CONFIG: Static URL1 'http://tracker.blitzortung.org/control/station.php'
2013-01-01 00:00:00 0 | REMOTE-CONFIG: Static URL2 'http://www.lightningmaps.org/control/station.php'
2013-01-01 00:00:00 0 | REMOTE-CONFIG: Checking every 300s
2013-01-01 00:00:00 0 |
2013-01-01 00:00:00 0 | === Tracker (TM by Egon) ===
2013-01-01 00:00:00 0 | TRACKER: Init Settings...
2013-01-01 00:00:00 0 | Tracker: Using buffer of 0bytes (0x10000000 - 0xFFFFFFF) for 35 signals
2013-01-01 00:00:00 0 | Tracker: Using buffer 35 for noise level calculation
2013-01-01 00:00:00 0 | TRACKER: Call Amplifier Setup...
2013-01-01 00:00:00 0 |
2013-01-01 00:00:00 0 |
2013-01-01 00:00:00 0 |
2013-01-01 00:00:00 0 | ===========================================================================
2013-01-01 00:00:00 0 | [Hard fault handler - all numbers in hex]
2013-01-01 00:00:00 0 | R0 = 80000000
2013-01-01 00:00:00 0 | R1 = 80e8
2013-01-01 00:00:00 0 | R2 = 3fd8
2013-01-01 00:00:00 0 | R3 = 3fd7
2013-01-01 00:00:00 0 | R12 = 0
2013-01-01 00:00:00 0 | LR [R14] = ffffffe9 subroutine call return address
2013-01-01 00:00:00 0 | PC [R15] = ff68df90 program counter
2013-01-01 00:00:00 0 | PSR = 2000003d
2013-01-01 00:00:00 0 | BFAR = e000ed38
2013-01-01 00:00:00 0 | CFSR = 1
2013-01-01 00:00:00 0 | HFSR = 40000000
2013-01-01 00:00:00 0 | DFSR = 0
2013-01-01 00:00:00 0 | AFSR = 0
2013-01-01 00:00:00 0 | SCB_SHCSR = 0
2013-01-01 00:00:00 0 | ===========================================================================
Stations: 1146
Reply
#4
(2014-08-16, 15:04)Christian.Weiss Wrote: Here the LOG.
It shows a brown out reset. Please check the supply voltage. It should be around 5V

(2014-08-16, 15:04)Christian.Weiss Wrote: Can i call you?
No, sorry. We don't have time for telephone support.
Stations: 538, 672, 1534, 1555, 1696, 1712, 2034, 2219
Reply
#5
(2014-08-16, 15:21)Tobi Wrote:
(2014-08-16, 15:04)Christian.Weiss Wrote: Here the LOG.
It shows a brown out reset. Please check the supply voltage. It should be around 5V

(2014-08-16, 15:04)Christian.Weiss Wrote: Can i call you?
No, sorry. We don't have time for telephone support.

No brown out, the voltage on the controller Board is 4,9 Volt.
The whole current is 280 mA and the USB Power supply has 750 mA.

Another idea?
Stations: 1146
Reply
#6
(2014-08-16, 16:04)Christian.Weiss Wrote:
(2014-08-16, 15:21)Tobi Wrote:
(2014-08-16, 15:04)Christian.Weiss Wrote: Here the LOG.
It shows a brown out reset. Please check the supply voltage. It should be around 5V

(2014-08-16, 15:04)Christian.Weiss Wrote: Can i call you?
No, sorry. We don't have time for telephone support.

No brown out, the voltage on the controller Board is 4,9 Volt.
The whole current is 280 mA and the USB Power supply has 750 mA.

Another idea?

Try a different USB cable, some of them have thinner gauge wires than they claim and can cause power problems (a common cause of problems with RaspberryPi boards).
If this does not help then try a different USB power supply, also check the quality of the mains supply, if the socket is old then I have seen problems with tarnished and even corroded contacts and loose screw terminals inside! also the same with extension cables.
I am currently using a 2.1A Apple USB adapter from an iPad and have no problems with power.
If none of the above help then you may need to consider either a UPS or fitting a large capacitor across the 5V rail to smooth any power dips.
Ben.
RED Station: 878,   Flightradar24: F-EGLF1,  Open Glider Network: Aldersht2, PlanePlotter: M7.
Stations: 878
Reply
#7
(2014-08-16, 16:21)Benedict.Smith Wrote:
(2014-08-16, 16:04)Christian.Weiss Wrote:
(2014-08-16, 15:21)Tobi Wrote:
(2014-08-16, 15:04)Christian.Weiss Wrote: Here the LOG.
It shows a brown out reset. Please check the supply voltage. It should be around 5V

(2014-08-16, 15:04)Christian.Weiss Wrote: Can i call you?
No, sorry. We don't have time for telephone support.

No brown out, the voltage on the controller Board is 4,9 Volt.
The whole current is 280 mA and the USB Power supply has 750 mA.

Another idea?

Try a different USB cable, some of them have thinner gauge wires than they claim and can cause power problems (a common cause of problems with RaspberryPi boards).
If this does not help then try a different USB power supply, also check the quality of the mains supply, if the socket is old then I have seen problems with tarnished and even corroded contacts and loose screw terminals inside! also the same with extension cables.
I am currently using a 2.1A Apple USB adapter from an iPad and have no problems with power.
If none of the above help then you may need to consider either a UPS or fitting a large capacitor across the 5V rail to smooth any power dips.
Ben.

We have connected the Board also to an Labor Power Supply from Hameg.
I can realy exclude problems with the Power Supply!

It looks like the Watch Dog on the STM Board is the Problem.

Here you can see a short Video
http://www.youtube.com/watch?v=IZiuj7jylc0
Stations: 1146
Reply
#8
I'm not sure, but this looks like a general problem with the processor. The hard fault error occur at unpredictable program counter values. Things you can try:

- Do a reset (black button) while holding the blue button for some seconds. This will erase the area in the flash memory where the settings are stored.
- Reflash the same firmware or a previous firmware
- Check again the soldering and placement of the parts
- Remove the Ethernet chip (ENC28J60) and/or the LCD and/or the amplifier
- Try a different discovery board
Stations: 538, 672, 1534, 1555, 1696, 1712, 2034, 2219
Reply
#9
(2014-08-16, 17:05)Tobi Wrote: I'm not sure, but this looks like a general problem with the processor. The hard fault error occur at unpredictable program counter values. Things you can try:

- Do a reset (black button) while holding the blue button for some seconds. This will erase the area in the flash memory where the settings are stored.
- Reflash the same firmware or a previous firmware
- Check again the soldering and placement of the parts
- Remove the Ethernet chip (ENC28J60) and/or the LCD and/or the amplifier
- Try a different discovery board

We have the Controller Board running after trying several Firmware Versions. Huh
V7.0b4 seems to be working but only as long as we connect the amplifier or the GPS receiver has locked. Lightning
We can connect the WebIF also as long there is nothing conected or the there is no valid GPS Signal.

Do we have to make settings in the WebIF bevor we can connect the amplifier?
Stations: 1146
Reply
#10
(2014-08-16, 20:02)Christian.Weiss Wrote: Do we have to make settings in the WebIF bevor we can connect the amplifier?
No, of course not. The system shouldn't crash at all, whatever you do.
Stations: 538, 672, 1534, 1555, 1696, 1712, 2034, 2219
Reply
#11
(2014-08-17, 06:03)Tobi Wrote:
(2014-08-16, 20:02)Christian.Weiss Wrote: Do we have to make settings in the WebIF bevor we can connect the amplifier?
No, of course not. The system shouldn't crash at all, whatever you do.

Hello Tobi,

thanks for reply.
I am a littlebit frustrated Confused

Right now i have the Controller Board running with FW 7.0b4.
Several hours.

The LCD shows:

CPU 3.0V 39°C 29%
Pwr 4.8 V
Firmware 7.0b4
PCB 10.4
No Ampplifier Connected
Didn´t receive valid data from GPS

Then i connect the external GPS Antenna and in the second the green GPS LED stops blinking the buzzer beeps and the LCD shows:

HardFault Error
LR=801734d
PC=801734e

Whenn i disconect the Power i can simulate the same Prozedure.

For me it looks like there is a software or config problem with the GPS Chip.
Reply
#12
I would say: check solder joints on the GPS chip Huh
Clément
Stations: 252, 680, 733, 1440
Reply
#13
Theoretically it's possible that malformated strings from the GPS chip produce some buffer overflow. But this is only one of a lot of more possibilities.

As you have already connected the serial output, you should enable the debug mode and check the messages there. Hold the blue button for a second while doing a reset. The LCD will show a hint that the debug mode is enabled. Press the blue button again to continue and check your terminal.
Stations: 538, 672, 1534, 1555, 1696, 1712, 2034, 2219
Reply
#14
(2014-08-17, 12:34)Tobi Wrote: Theoretically it's possible that malformated strings from the GPS chip produce some buffer overflow. But this is only one of a lot of more possibilities.

As you have already connected the serial output, you should enable the debug mode and check the messages there. Hold the blue button for a second while doing a reset. The LCD will show a hint that the debug mode is enabled. Press the blue button again to continue and check your terminal.

Hello Tobi,

i am still working on the same Problem and can´t realy get my controller board running.
The only Firmware Version witch is running and shows a Website is 7.04b.
Al other Firmware Versions are not working on my Hardware.
I can not understand why ?

Now i have the Board in the debug mode an the serial interface is connectet to the hyperterminal so i ca see the log.

How can you help me?

Christian
Reply
#15
Hello Christian,

A hard fault is an exception that occurs because of an error during exception processing, or because an exception cannot be managed by any other exception mechanism. Hard faults have a fixed priority of -1, meaning they have higher priority than any exception with configurable priority.

Debugging through the internet and/or forum won't be easy.

LR=801734d indicates that there is something wrong with a called subroutine.
PC=801734e is the programcounter

I'm fairly new at the forum so I can not comment on the software and which subroutine is called. Based on what you have written it may be the subroutine that is checking your GPS and is trying to read a value and when doing that an unexpected value is arriving at the processor. The signal should be at TTL-level. So as Tobi suggested it is wise to have a good look at the solderpoints with a magnifier.
Yes, the green leds stops blinking which should be an indicator that a GPS signal is found and locked to it but that stage lies at least 10-15 seconds futher away so the stopping of the blinking is only caused by the processor that stops executing the program.

Maybe one of the software developpers can confirm that the called subroutine is the one for the GPS-module.

Good luck!

Frank Veldhuijsen
[station 1152]
Reply
#16
We can not help until we didn't get any logs with debug output enabled (see post 13). So far there are no indications that the GPS is causing the problem. As the video shows alternating LR/PC counter values, we can not really rely on them.
Stations: 538, 672, 1534, 1555, 1696, 1712, 2034, 2219
Reply
#17
Christian, this may seem a strange question,....
Are you running the controller with power connected to both main and the Discovery Board, or just from the Discovery board? Make sure only main is connected...

We've had a handful of new builds with power connected to multiple ports, even a separate connections to Amplifiers,... the system only requires the main on the controller...

Mike

Stations: 689, 791, 1439
Reply
#18
Some time past since your last post...

Any updates on progress in searching the error?

Frank
Reply




Users browsing this thread: 1 Guest(s)