µTasker Forum > Luminary Micro ^TM LM3SXXXX

Code hitting irq_hard_fault(void)

(1/2) > >>

mhoneywill:
Hi Mark,

Just after a bit of advice, I'm using Rowley crossworks V1.7b22 and have an application, that seems to have problems running with the JTAG.

If I build the code as "Bare minimum bootloader" it works fine with the bootloader.
If I build it using the Rowley command "Build and Debug" in either "THUMB Flash Debug" or "THUMB Flash Release" modes it hits irq_hard_fault and thats it.
If I build it using the Rowley command "Build and Run" it builds but does not run (maybe it locks up as above) but if you press the reset switch it runs.

I can get arround this by building then resetting the board then attaching the debugger, but this operation is different to all the other projects I've created.

When I hit the irq_hard_fault loop the call stack does not show anything helpful, just irq_hard_fault.

Any pointers that might help me?

Cheers

Martin

mark:
Hi Martin

Sorry about being so quiet for the past few days - unfortunately I haven't experienced this behavior and therefore don't have any immediate suggestions.
Did you manage to get an improvement in the meantime?

Regards

Mark

mark:
Hi Martin

I have actually hit a similar problem after adding TFT touch panel control to a board with the LM3S1958 on it. The touch control uses a timer at 1kHz triggering ADC conversions - the completion of the conversion interrupts the processor.

The SW runs when reset but fails with hard error when working with the debugger. What I can't however do is connect after the board is running since it immediately goes to the hard error again after connection.

What I have however see is the following - I didn't find a work around yet though:
1) When the debugger connects it lets the board run for about 2.5s. In this time everything works normally since I can see images in the display and a PWM output is controlling its intensity.
2) The the debugger resets and stops at main()
3) What I noticed as that the PWM output was however still controlling the brightness although the debugger has supposedly just reset the chip. Looking at the peripheral power register all peripherals are still powered up.
4) What seems to happen is that when the touch screen configuration takes place the ADC already has samples waiting and, when the IRQ in the NIC is enabled it is in fact immediately interrupting although the ADC has neither been started. The interrupt handler is probably not ready and so it hard-faults.
5) What I saw was that an ADC source interrupt was pending in the NVIC even before the code had started. Even if I remove power to the timer and ADC I don't seem to be able to get rid of the pending interrupt.

For the moment I can't debug when the touch screen code is enabled...

Does your problem perhaps have a similar source???

Regards

Mark

mhoneywill:
Hi Mark,

Interesting thought, maybe the think to do is to put an Idle timer in the startup code that will wait for 1 - 2 secs in a loop at powerup, if you are in debug mode. This way the chip would not do anything (not enable any peripherals etc).

Its not the biggest thing on my list at the moment just a frustration.

Regards

Martin

mhoneywill:
Hi Mark,

I've done a bit of investigation on another board that exhibits the same symptons, in debug mode it hits irq_hard_fault. But runs if the debugger is not connected. Like you I've found it to be ADC related.

If I don't initialise the ADC then it works fine.

I noticed that fnEnterInterrupt was being called quite late in the routine and wondered if this needed to be setup earlier, I tried moving it up but still had the same problem :-(

Have you managed to make any progress with this?

Cheers

Martin
               

fnEnterInterrupt(irq_ADC_Sequence_0_ID, ptrADC_settings->int_priority, _ADC_sequence_0_complete); // enter the interrupt

Navigation

[0] Message Index

[#] Next page