Is it possible to destroy LPC43xx by accidental overclocking ?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Is it possible to destroy LPC43xx by accidental overclocking ?

542 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by jarekk on Fri Oct 02 01:36:09 MST 2015
Hi,

After merging some software we got a small problem - accidentally we got wrong PLL values for our combination of LPC4330 with SPIFI external flash ( too high core frequency).

This caused big problems with recovering from this situation - we were unable to reprogram SPIFI flashes again.
After several tests we have changed the flashes to new ones ( empty ), but the problem did not disappear - none of the two devices recovered.

So the question is - is it actually possible to destroy silicon by accidental overclocking ?
The funny thing is that the core actually still works, but SPIFI seems inoperational. On one devices the SPIFI flash is not seen at all, on the other board you can see SPIFI contents, but cannot write/erase.
Even with our code loaded to RAM - which works properly on other boards.

Our debugger - JLink reports timeouts on attempts to erase any of these flashes. Checked with Crossoworks and Keil as well as JFlash algorithms





Labels (1)
0 Kudos
Reply
2 Replies

503 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by jarekk on Tue Oct 06 07:14:26 MST 2015
Hi,

I think I have found out what went wrong.

We do use FPGA connected to EMC - as side effects some boot selection pins are shared with address lines ( and do have pull ups/down).
It worked nicely to a point when it .....suddenly stopped.  Hard to tell why there was coincidence with our firmware merge failure ( which caused too high CPU frequency).
I still do not know why it fails - the power on sequence seems clean, however FPGA power do comes a bit later ( 1.8 / 1.2 V )


I found out that these boot selection pins were sampled incorrectly and it was confusing ROM code up to a point where debugger ( both Jlink and ULINK2) could not connect and stop processor during flash programming - seems they do reset CPU during the programming process. Quite strange that even my own code did have issues accessing SPIFI.

Anyway - forcing SPIFI boot  with fuses ( well - with OTP commands) solved the problem.


0 Kudos
Reply

503 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by bavarian on Tue Oct 06 03:45:04 MST 2015
No, never experienced something like this.
However, I can't say if an LPC4330 running on e.g. 240MHz survives for long, because it's getting really hot.
But you already said that the MCU still works. So it's not damaged in general, But I've never seen that a SPIFI was damaged when the rest of the chip was still working.

I would give it a try with another way of programming the SPIFI:  you can use the UART bootmode with FlashMagic  http://www.flashmagictool.com/ and select the External Flash option (shown in attached picture).

Regards,
NXP Support Team
0 Kudos
Reply