On Monday 18 January 2010, Thomas Kindler wrote:
> > My own runtime code enables all faults, so that if I
> > override the default loop-to-self handler (by just
> > providing a non-weak symbol) it will always kick in.
>
> I tried that, also. But as I understand, the HardFault handler can be
> use
David Brownell wrote:
> On Monday 11 January 2010, Thomas Kindler wrote:
>> Joseph Yiu suggested this code to cause a hard-fault:
>>
>>__asm(
>> "movs r0, #1 \t\n" // unaligned ..
>> "ldm r0, {r1-r2} \t\n" // .. load-multiple
>> "bx lr \t\n"
>>);
>>
>>
David Brownell wrote:
> On Monday 11 January 2010, Thomas Kindler wrote:
>>> To clarify: it behaves fine after adding that line,
>>> no wierdness?
>> Not really - I still have to do one additional system reset using the
>> push-button. But it's way better than having to power-cycle for my
>
On Tuesday 12 January 2010, David Brownell wrote:
> On Tuesday 12 January 2010, Thomas Kindler wrote:
> > David Brownell wrote:
> > >
> > > Could you give the appended patch a try?
> >
> > I'd love to!
> >
> > But right now, I'm stuck with building libftdi under cygwin. In the
> > past, I on
On Tuesday 12 January 2010, Thomas Kindler wrote:
> David Brownell wrote:
> > On Monday 11 January 2010, Thomas Kindler wrote:
> >>> To clarify: it behaves fine after adding that line,
> >>> no wierdness?
> >> Not really - I still have to do one additional system reset using the
> >> push-button
David Brownell wrote:
> On Monday 11 January 2010, Thomas Kindler wrote:
>>> To clarify: it behaves fine after adding that line,
>>> no wierdness?
>> Not really - I still have to do one additional system reset using the
>> push-button. But it's way better than having to power-cycle for my
>> ap
On Monday 11 January 2010, Thomas Kindler wrote:
>
> > To clarify: it behaves fine after adding that line,
> > no wierdness?
>
> Not really - I still have to do one additional system reset using the
> push-button. But it's way better than having to power-cycle for my
> application.
Could yo
On Monday 11 January 2010, Thomas Kindler wrote:
> Joseph Yiu suggested this code to cause a hard-fault:
>
> __asm(
> "movs r0, #1 \t\n" // unaligned ..
> "ldm r0, {r1-r2} \t\n" // .. load-multiple
> "bx lr \t\n"
> );
>
> (see http://www.st.com/mcu/for
David Brownell wrote:
>>> If that's part of the issue, you might be able to
>>> work around it by updating DEMCR before shutting
>>> down. "cortex_m3 vector_catch none" maybe.
>> Well, it helps a bit. Adding "CoreDebug->DEMCR = 0;" to the start of my
>> program does the same.
>
> To clarify: it
On Monday 11 January 2010, Thomas Kindler wrote:
> David Brownell wrote:
> > On Monday 11 January 2010, Thomas Kindler wrote:
> >> How could this be fixed or explained?
> >
> > There's some curious voodoo in the Cortex-M3 code
> > where it mucks with fault handling ... see in the
> > cortex_m3_end
David Brownell wrote:
> On Monday 11 January 2010, Thomas Kindler wrote:
>> How could this be fixed or explained?
>
> There's some curious voodoo in the Cortex-M3 code
> where it mucks with fault handling ... see in the
> cortex_m3_endreset_event() routine where it sets
> up to trap some faults au
On Monday 11 January 2010, Thomas Kindler wrote:
> How could this be fixed or explained?
There's some curious voodoo in the Cortex-M3 code
where it mucks with fault handling ... see in the
cortex_m3_endreset_event() routine where it sets
up to trap some faults automagically. REVISIT
comments mark
Hi!
I just encountered a strange problem on my STM32F103 board.. I've
written a very simple hard fault handler that sets a LED output and
loops forever.
Everything works fine after initial power on. I can trigger a fault with
an unaligned load multiple operation and the handler will get cal
13 matches
Mail list logo
