LPC54628: a serious problem with ISP boot pins shared with SDRAM

[giusloq]

There are a couple of therads on this topic in this forum, but I didn't found any final solution from NXP.

The critical issue is when ISP pins (PIO0_4, PIO0_5, PIO0_6) are shared with SDRAM (EMC_D[2], EMC_D[3], EMC_D[4]). If you want to use an external SDRAM, you are forced to use these connections.

From time to time, when I restart the MCU through debug probe (J-Link), the Boot ROM is activated and the program flow hangs in an endless loop (debugger says the program counter is in 0x0300 0000 range).

The EVB doesn't have pull-up on ISP pins and this could be the cause of the problem. However some users on the forum reported the problem is still there after mounting pull-ups. This could be explained in the following way: if the reset happens when the SDRAM has configured D2-D4 pins as low-level outputs, MCU enters Boot ROM.

What is the official solution from NXP engineers?

[Gcat73]

Did you ever find a cause or solution?

[xiangjun_rong]

Hi,

After Reset, the ISP pins (PIO0_4, PIO0_5, PIO0_6)  on-chip pull-up resistors are enabled in default, so all the three pins are high, the cpu samples the three pins and get all high logic and start executing code from on-chip flash if valid user code is detected in on-chip flash.

Because the SDRAM data pins (EMC_D[2], EMC_D[3], EMC_D[4]) are connected to the above pins, it is possible that the SDRAM data pins (EMC_D[2], EMC_D[3], EMC_D[4]) maybe drive the the ISP pins during/after Reset, which leads to the fact that CPU gets a random value after sampling the above three pins. If you connect the EMC_DYCS pin of SDRAM to an external pull-up resistor, I suppose the SDRAM data pins (EMC_D[2], EMC_D[3], EMC_D[4])  will be float, in the case, the ISP pins (PIO0_4, PIO0_5, PIO0_6) will be high when cpu samples them, because of on-chip pull-up resistor.

I do not know if it can solve the issue.

BR

XiangJun Rong

[Gcat73]

The synchronous DRAM seems to require a clocked disable.  A simple pullup does not work in our experience except for specific SDRAM modes where it is used for bank select.

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 unless you have put the SDRAM in a special mode.
• 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.

[giusloq]

If you connect the EMC_DYCS pin of SDRAM to an external pull-up resistor, I suppose the SDRAM data pins (EMC_D[2], EMC_D[3], EMC_D[4])  will be float, in the case, the ISP pins (PIO0_4, PIO0_5, PIO0_6) will be high when cpu samples them, because of on-chip pull-up resistor.

On EVB, DYCS pin of SDRAM is connected to PIO1_12. This MCU pin has an internal pull-up resistor enabled at reset, so this connection should be sufficient to solve the problem as you said, but it isn't.

What I don't understand is why RESET pin is not sufficient to exit from Boot ROM and restart from sampling ISP pins.

Indeed it seems that, after entering Boot ROM caused by some ISP pins sampled low at reset, the MCU stays in the bootloader even if I assert RESET pin again.

[xiangjun_rong]

Hi,

If you connect external pull-up resistor(for example 5K~10K ohm) to all three ISP pins (PIO0_4, PIO0_5, PIO0_6) , after you press Reset, can the MCU execute application code in on-chip flash or stay in bootloader?

BR

XiangJun Rong

[Gcat73]

Once it hits the bootloader it stays stuck/frozen. No simple reset helps. Power must be removed.

A team member has discovered a post that lead to him generating hex files that work ONLY when the create is performed on a clean setup with certain files deleted to enforce a clean output.  That doesn't work on my board yet.  If I find the post I will ad the link.

[giusloq]

If you connect external pull-up resistor(for example 5K~10K ohm) to all three ISP pins (PIO0_4, PIO0_5, PIO0_6) , after you press Reset, can the MCU execute application code in on-chip flash or stay in bootloader?

Most of the time my application runs, but it sometimes happen that the MCU enters ROM Bootloader.

The bad thing is that the MCU stays in Bootloader even after pulling down RESET line (for example, by the pushbutton switch) 

[frank_m]

> The bad thing is that the MCU stays in Bootloader even after pulling down RESET line (for example, by the pushbutton switch) 

In "ancient" times, SBC and microcomputer designs used tristate line buffers or multiplexers with separate /OE pin to decouple the MCU/processor.  Not sure if that would be an option for you.

IO pins are a valuable resource on MCUs. It seems most vendors decide to pair critical functionalities like mode pins or JTAG/SWD pins with rarely used and resource-hungry "fancy" peripherals like displays or external memory. Just an observation, which does't help very much ...