Hi all. The flash wait-states were already at its maximum (set up for 72MHz), so I couldn't increase it. But instead I decreased the chip speed to 36 MHz and removed 50% of the NOPs in the code. Now it's been running for more than an hour, so this might be the fix, in case anyone else comes across such problems. I'll leave it running for a couple of days, just to make sure it still works. ;)
Thank you all for your help and suggestions. :) Love Jens On Mon, 8 Sep 2014 11:11:14 +0200, Andreas Fritiofson wrote: > > > On Sun, Sep 7, 2014 at 10:29 PM, Jens Bauer <[email protected]> wrote: >> Hi all. >> >> I just had this strange experience. It all sounds very unreal. >> >> First of all: a NOP that is HardFaulting. [...] >> >> What I find peculiar, is that ... reading memory from OpenOCD seems >> to be inconsistent. > > Hi! > > Just a thought... I have no experience with the LPC controllers but I > assume that they, like most, need a configurable number of > wait-states on flash access, depending on clock speed, Vdd range and > so on. Is it configured correctly? Maybe try to add an extra > wait-state to see if it makes a difference. Perhaps the oddly > behaving addresses belong to flash cells that are on the limit, and > temperature increase pushes it over after a while... > > If the target crashes on it's own, I think we can rule out OpenOCD, for now. > > I have no idea how the disassemble routine handles odd/even > addresses. I guess the correct address to pass is the even one, > without the T-bit set. > > /Andreas > ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
