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 MPU9250<xpcc::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...@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?
_______________________________________________
xpcc-dev mailing list
xpcc-dev@lists.rwth-aachen.de
http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
