LPC4357 All Interrupts stop working in External RAM, requires power-off/on to work again

[brich]

Hi, I have plenty of details to post about this problem, but before I take all that time, I wondered if anyone is aware of an issue that causes ALL Interrupts to cease to function suddenly, particularly after the second debug session, or a restart of a debug session.  I have an app that I have linked entirely to RAM, managed to initialize my external RAM with a jlinkscript and debugger probe.  This allows the debugger to download the image straight into external RAM, and start debugging.  Interrupts work fine the first time, but never on the second attempt to debug, or restart, unless power is removed from the device and reapplied first. 

I have made certain that interrupts are enabled, and I observe that almost immediately after enabling, the register that says interrupts are pending indicates several of them are.  But nothing happens.  No IRQ's fire.  I have tested this with at least 5 IRQ's.  Another weird thing is that even a HardFault will not fire after attempting to dereference a null pointer.  I didn't think you could even unhook that.

I have taken a look at all the NVIC registers, and have even observed a bit was set in the register that indicates which IRQ was presently being executed, but that IRQ never fired, and app code continued to be executed.  I really don't know where to go from here, other than require a power cycle of the unit to possibly reset whatever hardware is in there that fires the interrupt.

The only thing that seems to work is a power cycle, which is probably clearing out some register that I don't know about, but thought maybe someone else might know what is going on.

Any ideas?

[brich]

Hi Bernhard,

Thank you very much for your quick reply.

1. The entire application (minus a few buffers for USB and MSC) is linked to external RAM.  See the map file I have attached, and just search for _IRQHandler.  I did this by checking the box "Link application to RAM" in the linker.  My memory config consists of the following (the other two internal RAM banks are for locations of buffers to make USB faster, as well as update firmare, since this design is intended to be a flashloader).

configMemory[0] = name=SDRAM alias=RAM location=0x28000000 size=0x1000000 sizek=16M bytes flash=false RAM=true defaultRAM=true
configMemory[1] = name=RamLoc32 alias=RAM2 location=0x10000000 size=0x8000 sizek=32K bytes flash=false RAM=true defaultRAM=false
configMemory[2] = name=RamLoc40 alias=RAM3 location=0x10080000 size=0xa000 sizek=40K bytes flash=false RAM=true defaultRAM=false

My heap and stack are also in external SDRAM, as shown in this snippet of the map file:

0x2800abe0 PROVIDE (_pvHeapStart, DEFINED (__user_heap_base)?__user_heap_base:.)
0x29000000 PROVIDE (_vStackTop, DEFINED (__user_stack_top)?__user_stack_top:(__top_SDRAM - 0x0))

2. The clock frequency is 120MHz - both the CPU and SDRAM are running at this rate (see attached jlinkscript file).

3. When I launch a debug session after a cold start (by first applying power to the board, when the board is off), everything works normally.  When I disconnect from that session, and start a new one (and subsequent ones) without first powering off and on the board again, no IRQ's fire.  For example, I am mostly running the complete usbd_rom_dfu_composite example.  I set breakpoints inside any of the IRQ's (which I have temporarily placed debug volatile incrementing variables inside to make sure I can hit a breakpoint) , and evidently none of them will fire anymore.  Subsequent disconnects and reconnects of the debugger do not solve this problem.  Only a cold boot of the board (removing power and applying power) prior to a debug session seems to resurrect hardware triggering of these handlers.  Strangely, I can see in the register IABR (Interrupt active bit register) that indeed, corresponding interrupts should be executing, but are not, and never will be unless I remove power like I stated above and try again.  The app marches on as if it is un-interruptable.

4. Interrupts work perfectly the first time I debug from a cold start (I verified this with breakpoints), and I can see the demo code working (PC mounts a drive, and the virtual com port demo works.  A second debug session (like described before without removing power first) will produce no drive on the PC, and vcom does not work either.  

5. I use LPCXpresso, and debug with a Segger J-Link Ultra+.  I have attached my startup script which initializes external SDRAM.  I pillaged most of this from an example on the internet, but managed to get it working with my chip.  It is possible that I am doing something to interrupts in this script, or the reset procedure is not doing something properly, but my startup code in my application should honestly be overriding all of that.  For example, in cr_startup_lpc43xx I do NOT have DONT_RESET_ON_RESTART defined, so everything should be getting reset that can be from software.  Note that there appears to be no resetting of the NVIC anywhere.  This makes me think there is a bug somewhere in the silicon

6. The clock frequency is set by the jlinkscript at 120 MHz.

cr_startup and sysinit are both the same as what is given in the lpcopen examples.   I have stepped over the code in sysinit that assigns the vector table to the contents of register 0xE000ED08, and I can see that it retains the value.

I can't think of anything else that would cause this, and it has become a real head-scratcher.

Thanks again for your time considering this issue.

Regards,

Brad

[brich]

I believe I have found the problem in the device errata sheet.  There is actually a bug in the silicon related to the NVIC not being able to be reset (which uses PERIPH_RST which is non-functional).  See section RESET.2.

This is pretty strong evidence to me that my problem is limited to the scope of debugging and will not happen in the field.

Thank you very much.

Brad

[brich]

Whoops, I read that incorrectly.  The thing that doesn't work is NVIC_SystemReset.  Not the ability to reset the NVIC alone, which there appears to be no ability to do by software.  I guess I'm still left wondering if there is something else going on here.

[bernhardfink]

Hi Brad,

a few questions:

1. Did you make sure that ALL interrupt vectors point to the external SDRAM ?
   Or is it a mixed setup?
2. Which frequency are you working on for the CPU and the SDRAM interface ?
3. What do you mean with " particularly after the second debug session" ?
   -  When you are in the third debug session?
   -  When going out of the first debug session and entering the second one?
4. What do you mean with "Interrupts work fine the first time" ?
   Perfectly fine, or do you mean that you just see them pending?
5. Which debugger and compiler do you use?
6. You init the SDRAM with a debugger script, most likely based on the 96MHz CPU frequency which is set by the boot ROM code. Do you change the frequency later in your code ?

It would be good to see your system init functions, up to the point where you enter main()

Regards,

Bernhard.