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.

[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.

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.

[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).