LPC1343 IAP hard fault

[lpcware]

Content originally posted in LPCWare by kraln on Sat May 31 13:10:35 MST 2014
Hi All,

I'm having an issue whereby sometimes the IAP call to erase sectors on a LPC1343 doesn't ever return... but it erases the sectors. This leads to the awkward situation in which the watchdog kicks and the micro reboots with a completely erased internal flash.

I have reserved 32 bytes of memory for IAP as per the datasheet, relocated the relevant code to RAM, and disabled interrupts globally before attempting to use the IAP. Depending on the exact order of operations, I can either reliably cause a hard fault, or somewhat reliably avoid it.

I was wondering if there is any documentation, beyond the 32 bytes of RAM, on what the exact setup for the IAP commands should be? Or, failing that, any further best practices for avoiding lockups?

Regards,
Jeff

[lpcware]

Content originally posted in LPCWare by nxp_apps on Fri Jun 13 14:27:55 MST 2014
Hi,

Just to double-check, are you passing the correct frequency (in KHz) during the IAP calls? The frequency passed in during the IAP calls should be the CPU clock frequency.

Thanks.

nxp_support

[lpcware]

Content originally posted in LPCWare by mubes on Wed Jun 04 00:23:12 MST 2014
That would be worth a try - or even moving to the internal osc as an experiment as the chip is completely left to its own devices at that point.  Its difficult to think of anything other than clocks and PSU stability that could have an effect once you're _in_ the ISP (as ints are off), and since you're saying that the chip is erased we have to assume that you're making the transition from your code to the ISP code OK.

Regards

DAVE

[lpcware]

Content originally posted in LPCWare by kraln on Tue Jun 03 16:54:24 MST 2014
Hi Dave,

The watchdog is set for a few seconds, much longer than the process takes.

One thing that might be interesting is, the behavior isn't entirely deterministic. I set up a test where the firmware updates itself (to itself) over and over and over, and sometimes it will fail after the fourth or fifth go-around. I had some issues a while ago with alignment to the IAP call, but I don't think any structural problems are at play here because it's the *same* code that sometimes works and sometimes fails.

Is it worth dropping to a lower clock rate (running at 72MHz normally) for the IAP calls?

Regards,
Jeff

[lpcware]

Content originally posted in LPCWare by mubes on Sun Jun 01 16:47:01 MST 2014
Very odd.  Once you've hit the ISP with interrupts off there's little that should be able to get in the way..it might be an idea to check your clocks and PLL settings to make sure you're stable but after that nothing obvious springs to mind. What interval is the watchdog set for?

Dave

[lpcware]

Content originally posted in LPCWare by kraln on Sun Jun 01 09:38:13 MST 2014
Hi Dave,

Thanks for the comment. Normally I'd agree with you, and in fact the rails are the first thing I looked at. In this particular application, the power supply is well overbuilt as there are a bunch of ISM band transceivers and relays and so forth attached. Also, on the same hardware, different firmware 'configurations' (features enabled at compile time) behave differently, from working 100% of the time, to sometimes failing, to always failing.

Regards,
Jeff

[lpcware]

Content originally posted in LPCWare by mubes on Sun Jun 01 06:42:07 MST 2014
Hi Jeff,

Voltage droops/poor decoupling are the usual culprit for this problem...have a good hard stare are your rails while you're entering/in ISP and see if they show anything abnormal.  I'm told the programming process takes a fair amount of power, but I've never gone to the trouble of measuring it.

Good luck

Dave