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.
Thanks for the help, though :)
Antal 2016. jan. 9. de. 12:46 ezt írta ("Szabó Antal" szabo.antal.92@gmail.com):
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=...)
atD:\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?