Disclaimer: I didn't yet rewire the whole thing according to the hardware development doc (I actually don't do the electronic part, but told the guy who does to fix it according to the doc), so this might be caused by electronic errors.

2016-01-09 0:37 GMT+01:00 Szabó Antal szabo.antal.92@gmail.com:

I got another one:

(gdb) where #0 _hardFaultHandler (ctx=0x2000bed0) at build\libxpcc\generated_platform\driver\core\cortex\hard_fault_handler.cpp:39 #1 <signal handler called> #2 0x080016be in I2C2_EV_IRQHandler () at build\libxpcc\generated_platform\driver\i2c\stm32\i2c_master_2.cpp:352 #3 <signal handler called> #4 0x08000a24 in pushRf (this=0x2000bf88) at D:\Prog\xpcc_test\xpcc\src/xpcc/processing/resumable/nested_resumable.hpp:163 #5 readFromReg (size=6, this=0x2000bf88) at mpu9250.hpp:75 #6 MPU9250xpcc::stm32::I2cMaster2::readAccel (this=0x2000bf88) at mpu9250.hpp:60 #7 0x08000bec in main () at main.cpp:40

This time the first interrupt happens inside an RF_BEGIN macro at this location:

(gdb) frame 4 #4 0x08000a24 in pushRf (this=0x2000bf88) at D:\Prog\xpcc_test\xpcc\src/xpcc/processing/resumable/nested_resumable.hpp:163 163 return rfStateArray[rfLevel++]; (gdb) l 158 /// increases nesting level, call this in the switch statement! 159 /// @return current state before increasing nesting level 160 rf::State inline 161 pushRf(uint8_t /*index*/) 162 { 163 return rfStateArray[rfLevel++]; 164 } 165 166 /// always call this before returning from the run function! 167 /// decreases nesting level

However, the first interrupt might be a legit I2C interrupt, but then again it hard faults.

The part where it hard faults is:

(gdb) frame 2 #2 0x080016be in I2C2_EV_IRQHandler () at build\libxpcc\generated_platform\driver\i2c\stm32\i2c_master_2.cpp:352 352 if (writing.length > 0 || reading.length > 3) (gdb) l 347 // EV6: ADDR=1, cleared by reading SR1 register followed by reading SR2. 348 DEBUG_STREAM("address sent"); 349 DEBUG_STREAM("writing.length=" << writing.length); 350 DEBUG_STREAM("reading.length=" << reading.length); 351 352 if (writing.length > 0 || reading.length > 3) 353 { 354 DEBUG_STREAM("enable buffers"); 355 I2C2->CR2 |= I2C_CR2_ITBUFEN; 356 }

which doesn't make much sense to me, as that line is just arithmetic comparisons.

2016-01-09 0:19 GMT+01:00 Szabó Antal szabo.antal.92@gmail.com:

...

Hi!

Thanks for the advice in the previous thread. I fired up gdb, and ran the program several times. This is the stack trace I get most of the time:

(gdb) where #0 _hardFaultHandler (ctx=0x2000bea0) at build\libxpcc\generated_platform\driver\core\cortex\hard_fault_handler.cpp:39 #1 <signal handler called> #2 0x08101374 in ?? () #3 <signal handler called> #4 xpcc::BufferedGraphicDisplay<(unsigned short)160, (unsigned short)128>::drawImageRaw ( this=0x20000854 hardware::lcd, upperLeft=..., width=5, height=8, data=...) at D:\Prog\xpcc_test\xpcc\src/xpcc/ui/display/buffered_graphic_display_impl.hpp:92 #5 0x080011b0 in xpcc::GraphicDisplay::write (this=0x20000854 hardware::lcd, c=<optimized out>) at D:\Prog\xpcc_test\xpcc\src\xpcc\ui\display\graphic_display_text.cpp:115 #6 0x080011d8 in xpcc::GraphicDisplay::Writer::write (this=<optimized out>, c=<optimized out>) at D:\Prog\xpcc_test\xpcc\src\xpcc\ui\display\graphic_display_text.cpp:139 #7 0x08000d86 in xpcc::IOStream::writeInteger (this=0x20000858 hardware::lcd+4, value=48) at D:\Prog\xpcc_test\xpcc\src\xpcc\io\iostream.cpp:55 #8 0x08000dc0 in xpcc::IOStream::writeInteger (this=0x20000858 hardware::lcd+4, value=<optimized out>) at D:\Prog\xpcc_test\xpcc\src\xpcc\io\iostream.cpp:35 #9 0x08000c40 in operator<< (v=<synthetic pointer>, this=0x20000858 hardware::lcd+4) at D:\Prog\xpcc_test\xpcc\src/xpcc/io/iostream.hpp:206 #10 main () at main.cpp:41

What I get from this is that something causes an interrupt while drawImageRaw is running, and then tries to jump to 0x08101374, an invalid address, which causes the hard fault.

The code in frame 4 is:

87 uint16_t row = upperLeft.getY() / 8; 88 uint16_t rowCount = (height + 7) / 8; // always round up 89 90 if ((height & 0x07) == 0) 91 { 92 for (uint_fast16_t i = 0; i < width; i++) 93 { 94 for (uint_fast16_t k = 0; k < rowCount; k++) 95 { 96 uint16_t x = upperLeft.getX() + i;

Line 92 is the for loop header, and I don't see anything that can go wrong here.

Also, it's not the exact same invocation where it crashes, the upperLeft parameter of drawImageRaw is different every time.

Can you suggest anything I should try next?

Hi,

On 13/01/16 20:09, Szabó Antal wrote:

Hi,

We modified the board to follow what you suggested, but there wasn't any real improvement. However, lowering the system frequency to 32 MHz "solved" all the problems, the test program correctly ran overnight without crashing. I don't exactly know what causes this, possibly some kind of interference, so I suppose you can't say anything without actually seeing it.

Good to here, that it works at 32 MHz. I and other people from the robotics club had a look at your traces, but we could not think of anything, that would cause them.

Kevin

Hi,

...

I and other people from the robotics club had a look at your traces, but we could not think of anything, that would cause them.

Thanks for looking into it! That's probably because they are caused by the hardware (which I suspected all along).

Regarding the hardfault: Have a look at the reported reason for the hardfault, not just the callstack.

In particular you want to look at the registers - SHCSR - CFSR - HFSR - DFSR - MMAR - BFAR - AFSR

which are all part of the System Control Block (aka. SCB). You can read them all at once starting at 0xE000ED24 and reading 7x 32bit words.

The information in there will tell you what the processor thinks caused the hardfault.

A detailed description of the registers and their meaning can be found in the ARM Cortex-M3 Devices Generic User Guide: http://infocenter.arm.com/help/topic/com.arm.doc.dui0552a/DUI0552A_cortex_m3...

Hope that helps, Niklas