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  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.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?