Posted on May 17, 2011 at 13:12Resolved! I made the fatal mistake of accidentally writing sizeof(buffer) instead of countof(buffer). Instead of an incoming buffer of 200 bytes, I ended up with 800. We do it that way because our buses utilise u8, u16 and u32 formats and are centralised (as buffers of u32's). Each driver then works out how many words, half words, or bytes it has (e.g. 2x or 4x). So, when running this wasn't a problem because the buffers would always be quickly emptied. When debugging and an interrupt was jumped in to, because I was stepping, the code ran really slowly in the background allowing the incoming buffers to fill up and overflow - blatting the peripheral pointers that were located some 200 words further up in memory.
Resolved...
Resolved... Feeling like a bit of a diddle!!!!
🙂 Resolved...
Hi all, I'm struggling to work out what info to include here in the hopes someone might have encountered this before.
Bus Fault Status: 0x82
Hard Fault Status: 0x40000000
Bus Fault Address: 0xF194C94E (what?)
The scenario is as follows...
I'll set a breakpoint (Rowley CrossWorks w/ ARM-USB-OCD) somewhere in my main loop or one of the tasks it calls.
Communications is still running in the background (incoming comms on USARTs and SPI).
I'll start stepping through the main loop and then bang, HFE. The fault details are above.
Just to clarify, if I leave the device to run and don't debug then CRC access works without a problem. Very quantum.
What is happening when I'm debugging is that data is arriving in the background and is calling one of the IRQ handlers which eventually makes it's way to a small function that uses the CRC peripheral.
So, I could just as well be in my main loop stepping through a continuously incrementing variable and this would still happen.
Going back through the call stack I can see that the fault occurs when reading CRC-IDR (would probably occur on any of those registers). Placing a watch on the CRC pointer (defined by the STM32 FWLib) I can see that the CRC peripheral pointer is now pointing to an out of bounds.
CRC pointer address: 0xF194C94A
Bus Fault address: 0xF194C94E
Interestingly, the IDR register has an offset of 0x04 from the CRC base address. The fault is occurring as I read CRC->IDR in to a local U32.
Putting all that aside for a moment. If I set a breakpoint at that same location (var = CRC->IDR) and reset the processor I can hit this breakpoint 20+ times without the HFE triggering (i.e. Run & wait for breakpoint). All during this time the CRC peripheral pointer's address is 0x40023000, which is where it should be!
I've stuck a counter in the function that reads CRC->IDR and it's telling me that when stepping through the main-loop code the HFE is happening the very first time that CRC calc function is called. Yet with the breakpoint sitting within that function I can hit it numerous times without fault (and then step through quite a ways...)
It's almost as though the CRC peripheral pointer is being corrupted, but then how can that be happening when stepping but not when running (still in debug mode). Increasing stack sizes doesn't fix anything, I only appear to be using around 500 bytes out of 1024.
Can anyone point me in a direction to track this down please?
Thanks very much
[ This message was edited by: darcy.williams on 18-05-2009 07:27 ]
