LPC54628 sometimes hangs in ROM boot loader after software reset

[jking1]

Hi

Our app, running on the LPC54628, requires a software restart when updating firmware. We do this with a call to NVIC_SystemReset(). Most of the time this works but sometimes the processor gets stuck in a loop and fails to restart correctly.

According to the debugger the program counter stalls at 0x30012C2 which I guess is somewhere in the ROM boot loader code.  .

When this happens the uProc does not respond to the reset pin and the only way to recover is to cycle the power.

Because this behaviour is somewhat intermittent we haven't been able to diagnose the problem so far.  We'd really appreciate some suggestions as to what might be going on.

[Gcat73]

We have confirmed the crash / freeze problem is:

• The SDRAM when operating, and when the hardware or software reset becomes active while the SDRAM is grabbing the data bus / outputting data, that data WILL STAY ON THE DATA BUS and the ISP pins send your system searching for good code to load. The variable data output by the SDRAM and the possible disabled outputs during normal operation cause the intermittent errors. SOLUTION: Only killing power to the SDRAM prior to or at the beginning of RESET, or clocking through any command that removes the output from the bus will work. Changing the logic state of an SDRAM synchronous disable pin will not work unless clocked through.
• The bootloader code succeeds or then crashes / stalls / faults / gets stuck and requires a power cycle OFF-ON to recover.
• Not the pullups.  The internal pullups work fine.  External pullups as low as 2.2k seem to leave plenty of margin for logic levels and speed.  YMMV.  Please test it yourself.

What we do not know, but are close:

• the exact procedure to 100% disable the read of the ISP pins during REST bootloader operation?
• The reason for the fault in the bootloader code?
• Why a watchdog RESET or software RESET do NOT provide an output on the nRESET pin?

Links to the answers for the above questions would be welcome.

[carstengroen]

For what its worth,

all my LPC54606 and LPC54628 designs uses 10 K pullup on D2,D3 and D4 (also in my '628 designs with SDRAM) and this works perfect. I too use NVIC_SystemReset() (after uploading new application via my own bootloader), and I have not seen it fail one single time yet (many many boards).

[jking1]

Thanks for this information.  Naively perhaps we followed the dev card implementation which, as you know, doesn't use pullups and I don't recall seeing any mention of their need in any NXP documentation.  

We can add pullups as and when we re-spin the card but I'm still hopeful we can find a firmware solution before this.  I've raised a ticket with NXP to see if I can get some advice from an engineer with experience of the ROM bootloader code.

In any case it's comforting to know that  10K pullups on D2, D3 and D4 presumably don't affect the SDRAM/EMC interface. 

[ZhangJennie]

From your description, your code enter Boot Rom after executing SW reset.

I suggest you identifying the problem on HW or SW.

bypass ISP, Make sure all ISP pins pull up. see if the problem persists.

ZhangJennie_0-1623911089246.png

It's possible your code invoke ISP by accident ( see Reinvoke ISP command). this will also cause code enter boot rom. if so, you need check your code  by self.

Have a nice day,

Jun Zhang

[Alice_Yang]

Hello jking1,

How about use a simple project that includes NVIC_SystemReset(). ?

It's better  share a project that we can reproduce the issue.

BR

Alice

[jking1]

Hi Alice

The problem we have is that so far we cannot reproduce the problem using NVIC_SystemReset() in a simple program using either our board or the NXP dev card. 

That is why I though that finding out what is going on at 0x30012C2 in the ROM bootloader (where the boot process hangs) might provide a clue for us. Also note that the call stack entry prior to 0x30012C2 is 0x30008A6. (Call stack screen  grab attached). 

[belmontbob59]

When you say "stall" you mean that when you single step the code the Program Counter  register (PC) isn't advancing ? This suggests a fault and not a loop.

[jking1]

The program counter does not increment which, as you say, suggests a fault rather than a loop.

[jking1]

Hi

Yes, we've got an SDRAM hooked up to the EMC pins in exactly the same configuration as the NXP dev card.  We're aware that the EMC D2, D3 and D4 share function with ISP0, ISP1 and ISP2.  We connect the debugger ISP pins via 2K2 resistors as per the dev card schematic.  We see the processor intermittently hanging during reboot with and without the debugger connected.

We are wondering if the fact that the processor always stalls at 0x30012C2  when it fails to reboot might be a clue.  Note that when the processor stalls on reboot it requires a power cycle to recover.  On the other hand, if we reboot the processor into a valid ISP mode by manually holding the relevant combination of ISP pins low then it always responds to the reset pin and does not require a power cycle.  Perhaps this is another clue?

[belmontbob59]

NXP "boots" into auto mode (i.e. scanning all individual inputs (SPI, UART etc..) for a valid image. it sounds to me like you might need external  pullups on these ISP pins to guaranty autoboot mode upon MCU reset. Did you put a scope on these ISP pins to determine there state upon reset ? 

However I don't know enough about EMC to determine if adding external pullups are going to  interfere with you SDRAM.

[Gcat73]

I have tested my system with 2.2k to 12.2k pull ups and the SDRAM seemed to work without problems.  However the processor still faulted and refused to respond to hardware reset pins when it read the wrong bits or found another unknown reason to halt and ignore everything other than a power cycle.

There is an unknown post indicating a clean compile works.  The "clean" status is based on deleting certain files before compile.  I am trying to get the link to the post.

Please post links to solutions.  The hundreds of views confirm this lockup is still a problem.

[jking1]

Hi Gcat73

The solution is to use your nReset signal to the LPC54628 to control power to the SDRAM.  You can use a load switch or a couple of mosfets to switch off power to the SDRAM during reset.  With this solution you can maintain the pullups at 2k2 as in the dev card reference design.

[jking1]

Yes, we wondered about pullups but the NXP dev card doesn't use them and we're using the same type of SDRAM.  Monitoring with a 'scope suggested that the ISP pins are all high at reset time but because of the intermittency it is hard to be absolutely certain.  I still think that the location in the ROM boot loader where the program stalls and the fact that it doesn't respond to the reset pin should provide a clue.  Are there any NXP engineers monitoring this forum I wonder?

[belmontbob59]

Do you have any of the ISP pins wired ? NXP boot reads these pins to determine how to boot (USB DFU, SPI, UART,... internal flash).