[SOLVED] Dead LPC1788 ?

[lpcware]

Content originally posted in LPCWare by Jacquot on Thu Oct 23 04:11:17 MST 2014
Dear LPC community,
I have been using an LPC1788 for a while now [on an FDI uEZGUI-1788-70WVM board]. As a debugger, i use the J-Link LITE ARM from SEGGER. For the IDE, i use CrossWorks for now....

I was pretty happy about all of these [except the fact that the debugger cannot `stop processor' quite frequently] until this morning. Indeed I've been developping for some months on this platform and very often flashing the device, it used to work well.

This morning i flashed the device several times and after a while i ended up with a "Can't find debug component in ROM table" message.
I checked everything that may seem related to this issue for me, but i cannot find any solution to this, and my device is now not powering up [i mean, i can see the power supply LED on, but the screen does not light or anything] and reluctant to being flashed [still the same error message]
The checks i have made are as follow :
- Check power supply : OK [checked with another board and it works]
- Check USB cables/various connections [PC<->Debugger, debugger <-> board looks okay too]
- Launched the JLINK commander, i get the following message

WARNING: at least one of the connected devices is not JTAG compliant

and then the commander checks for JTAG, SWD, FINE, in both normal and slow speed and cannot find anything
- Tried to connect to the target using Flash Magic with no success
- Tried to plug/unplug power supply multiple times without any noise/light from the board

I am afraid i broke everything though the firmware i flashed in the last session was roughly the same as before and i am not hacking lowlevel things, just doing a basic GUI with it.

Crawling through the forum i'm aware of this http://www.lpcware.com/content/forum/lpc1788-cannot-find-debug-component-rom-table which seems useful, but i wonder whether i should dig into this since i did not play with anything as low level as the OP.

Any help would be appreciated, i used to like this board
Thanks in advance !
J.

[lpcware]

Content originally posted in LPCWare by martinayotte on Thu Jan 08 15:51:47 MST 2015
I've received some spare LPC1768. Should I start my dremel to cut my defunct one or should I wait ? :-0

[lpcware]

Content originally posted in LPCWare by martinayotte on Tue Jan 06 12:12:05 MST 2015
Hi capiman,
Unfortunately, I don't have a JTAG dongle. But I think I should get one, since it will always be useful.
I'm uploading 2 versions of the firmware, since I don't which one I've used when the drama occurs, because I've continued some work that day with another board.
There are about 2 hours differences between both builds. (Note : there are not both from same sources, there are 2 different versions found on the web, that I've translated/modified for the GNU toolchain).
If those binaries inspires you, thanks in advance for your help :-)

Oh ! looking at timestamp of my original post, it should be usbbootloader-badfirmware.zip, since the other seems to be after my post (if timezones are ok)

[lpcware]

Content originally posted in LPCWare by capiman on Tue Jan 06 11:45:46 MST 2015
A colleague of me was once able to recover my board via JTAG. But I can't tell how he has done it, via JTAG or SWD?
I think he told me he has tried it again and again with a fast JTAG clock and suddenly he was able to access and delete the chip.
Perhaps also something to test, if you have a working JTAG dongle...
(I don't think it is the CRP3, something else which we don't yet know).
PS: Do you have the exact same firmware (latest one) which you flashed, where the problem occurred? If yes, can you store it (or even upload it)?

[lpcware]

Content originally posted in LPCWare by martinayotte on Tue Jan 06 11:38:28 MST 2015
Hi capiman,

Yes, I did ... same thing, it goes directly to start by defective firmware ...

Lesson learned : if the whole story is really what I'm thinking of, I will add new code to my default handler, not only blinking LED, but provide a "backdoor" to clear that CRP3 state ... :-)

[lpcware]

Content originally posted in LPCWare by martinayotte on Tue Jan 06 11:35:05 MST 2015
Hi Jacquot,

I didn't try "flashmagic" since I'm working almost exclusively on Linux, so that why I'm using "lpc21isp".
Maybe I will try it, although I'm doubt it will work, since I tried also to enter in ISP using manual typing in TTL-Uart, except if there another "backdoor" that "flashmagic" is using and that is not documented somewhere.
What do you mean by "automatic clock detection" ? Do you mean the "autobaud detection" of ISP mode ? The ISP mode doesn't even start when P2.10 is low, CPU goes directly into my defective firmware, clocking properly (since I have even a Reset banner into the Uart at 115200B just before it hangs in my DefaultHandler, blink a LED)
Anyway, thanks for the advice, I will stil try that famous "flashmagic" later today.

[lpcware]

Content originally posted in LPCWare by capiman on Tue Jan 06 11:33:31 MST 2015
Just an idea: Have you tried to power-up the board to get into ISP mode instead of pressing reset button?
(Assuming ISP pin already has the right level)

[lpcware]

Content originally posted in LPCWare by martinayotte on Tue Jan 06 11:25:42 MST 2015
Hi TheFallGuy,

I played with this board for almost 3 weeks, using "lpc21isp" to upload different samples over the days, playing with some code, even have some I2C peripherals hooked-up.
I've even written small python application that communicate in ISP to be able to do a "Read-Dump" of the current Flash (taking care of sector 0 remapping) because "lpc21isp" doesn't have such function, this allowed me to do a backup of another board, my Mini-DK2, for which I didn't have a backup of the demo firmware. All that to say that I'm now quite familiar with the ISP protocol, "?" to autobaud-sync, then "Syncrhonized" exchange, etc.

After almost more than 100 firmware uploads, while playing with USB secondary bootloader code, which I didn't make it work yet (except by using pre-built binary), I was suddently stuck by not been able to upload again. Stuck trying to enter in ISP even using a TTL-Uart manually sending "?". The CPU fall directly into my defective bootloader, flashing my debug LED. If it was in CRP1 or CRP2, I would have been able to reflash, but I think I don't have other issue to throw awat the chip and replacing it (I've ordered some ast night)

[lpcware]

Content originally posted in LPCWare by Jacquot on Tue Jan 06 08:06:51 MST 2015
Ok, well i got your point...
I just told you this because i had exactly the same thought at first: my chip is dead into CRP3...and i cannot go to ISP mode...  then i flashed it using flashmagic as written earlier, successfully.
It was just it was not clear for me that you tried to re-flash the chip + stop using automatic clock detection [since both of those steps were meaningful for me]. I guess you should try to explicitly tell here what you have tried to state it's dead... especially if you tried the whole procedures cited here as references...
Sorry the intervention.

[lpcware]

Content originally posted in LPCWare by TheFallGuy on Tue Jan 06 08:01:37 MST 2015
Are you sure you are following the correct ISP procedure. Suggest you tell us what you do to try to get it into ISP mode.

[lpcware]

Content originally posted in LPCWare by martinayotte on Tue Jan 06 07:31:02 MST 2015
Hi Jacquot,

My chip doesn't want to jump to ISP mode, that's the whole issue since the beginning.
It is jumping straight thru my defective firmware which hang on specific instruction.
According to the definition of CRP3 :

---

Quote:
In a higher level of protection, the user can also prevent others from downloading their
own code, which would mean some kind of hardware protection, i.e., it will prevent others
from reusing the hardware. In this last case, CRP3 prevents entering ISP by pulling
P2.10 low (hardware mechanism which allows entering ISP when there is valid code in
the user’s flash). In this way, unauthorized users can’t use ISP to access the device
flash, so this mode provides the maximum level of protection.
The user should note that in effect, with CRP3 there is no way to update the user flash,
which means no further code updates are possible. However, the user code could make
use of Re-Invoke ISP (one of the In-Application Commands – IAP) which invokes the
boot loader in ISP mode.

When we use Re-Invoke ISP, we are breaking CRP3 protection, which ultimately means
we are downgrading to level CRP2. Although in this level we can’t read the flash, we can
download a new code. Of course, the user code should already have this “back door”
prepared in order to break CRP3 when necessary, and the mechanism used for this
would be kept secret as it will be the key to break with the hardware protection, as we
saw above.

---

[lpcware]

Content originally posted in LPCWare by Jacquot on Tue Jan 06 01:58:20 MST 2015
Dear Martinayotte,
I'm not an LPC expert, but by any chance, have you tried the solution that did work for me:

---

Quote:

- Put the board in ISP mode
- Flash while holding this mode, using an official firmware and FlashMagic
- Remove adaptive clocking and set the clock speed to something slow [100kHz ?]

---

Just to be clear, did you try the 2nd {flashmagic} and 3rd {remove adaptive clocking} points

Best luck for your issue,
Since it is unlikely that your chip is dead, i guess you'll soon find a solution !

Cheers,

[lpcware]

Content originally posted in LPCWare by martinayotte on Mon Jan 05 15:47:29 MST 2015
Hi,

@capiman, I've looked at RSTOUT, and it reflect exactly the RST done using the push button.
Also, I wasn't suspecting Reset every millisec, since it is stuck in my DefaultHandler code where I've placed a small loop blink a LED with one short blink followed by a long one.

@TheFallGuy, I know that probabilities are thin, but what can it be otherwise ? My previous assumption of chinese clone getting into a erased ROM ?
As I said, my DefaultHandler is blinking the LED, so the CPU is working fine, but ISP is prohibited somehow ...

BTW, I've just verify something : The UART is also initialized properly because I've added UART_printf in ResetHandler and some other place, I receive them properly because it goes in DefaultHandler.

I wish the NXP had provided some other method to unlock CRP3, such High Voltage erasing ... :-(

[lpcware]

Content originally posted in LPCWare by capiman on Mon Jan 05 00:46:13 MST 2015
Can you check RSTOUT? I had once a case with a LPC1768, where the chip resetted again and again (once every 1ms)
and internal bootloader was not accessable anymore.

[lpcware]

Content originally posted in LPCWare by TheFallGuy on Mon Jan 05 00:35:25 MST 2015
It is very very difficult to select CRP3 accidentally. You need to place the value 0x43218765 at address 0x2fc. Using a bootloader will not do this unless you specifically set the value at the address

[lpcware]

Content originally posted in LPCWare by martinayotte on Sun Jan 04 20:13:14 MST 2015
Hi R2D2,

Unfortunayely, I've already seens those links... :-(
For the P2.10 button, I've already try to take a jumper on P2.10 and short it to ground.
No way, Reset jump directly to my bad firmware.

In your second link, the following quote confirm my fears :

---

Quote:
CRP3 (Level 3): No ISP access. Even NXP can't access the code a CRP3 level. IAP reprogramming is possible

---

(in the AN, it is mentionned on page 4 as I read before : "the user code should already have this 'back door' prepared in order to break CRP3 when necessary")
Unfortnately, my bad firmware can't provide me such backdoor.
So, the chip is really bricked !!!
NXP really make this difference between CRP2 and CRP3.
(I've even read in my searches that some board companies are not responsible for any returned boards which are in CRP3 state)
I will have to unsolder and resolder new chip :-(

[lpcware]

Content originally posted in LPCWare by R2D2 on Sun Jan 04 19:12:23 MST 2015
http://www.lpcware.com/content/faq/lpcxpresso/regaining-debug-access

is describing how to boot into ISP  :)

In your case: ground ISP pin (P2.10) and power cycle your board...

http://www.lpcware.com/content/faq/what-are-code-read-protect-crp-levels-lpc17xx

is describing CRP modes.

Perhaps your cheap board has hardware problems (button), so checking ISP and Reset could be useful...

[lpcware]

Content originally posted in LPCWare by martinayotte on Sun Jan 04 16:30:58 MST 2015
Since yesterday, the more I think about the issue, the more I become frustrated !
This BOOT ROM should be a ROM ! How can it be erased or disconnected from the Reset bootstrap flow ?
I came to the conclusion that since my board come from China, it is possible that the LPC1768 is in fact a clone one which probably has a ROM which is in fact another Flash, been erased somehow ...
(Fortunately, I can continue my experiments using another board, from China too, an Mini-DK2. The defective one was a Minimal-MCU123. I won't play too much with Secondary-Bootloader code like yesterday, I'm so afraid to brick another one)
I will now order some genuine chips to replace the defective one and use the other for real prototyping...

Edit : I found something interesting but embarrassing :

---

Quote:
Caution:
If CRP3 is enabled, changes to the
flash space can only be performed using
IAP in the user application. Assuming a valid
user application is present, the secondary
USB bootloader will NOT enter ISP mode if CRP3 is selected.

---

This means that probably my chip entered in CRP3 somehow, and there is no way to clear that since my code enter in DefaultHandler ! So, it is definitely bricked ! :-(

[lpcware]

Content originally posted in LPCWare by martinayotte on Sat Jan 03 16:10:37 MST 2015
I've got a small LPC1768 board from eBay since few weeks.
I've played a lot with it, uploaded several code examples using lpc21isp while pressing the P2.10 button.
Unfortunately, this afternoon, after uploading a bad firmware, the ISP mode was not accessible any more.
Even pressing the P2.10 button, it never turn on the ISP mode, it is jumping straight into my bad firmware.
To confirm that, I'm seeing on serial port the startup banner of my before it reach the bad code.
Since I'm used to add a blinking LED into the DefaultHandler of all my samples to ease debugging, and when it reach the bad code, that LED start blinking.
I've also tried to open serial terminal and directly trying to send few "?", and I never got a "Synchronized" answer. I wish to enter ISP mode but no response.
It sound strange to me since the ISP bootloader is in ROM, so it must have some precedence over my fault code...
Any idea ? Is the chip bricked (but I can't believe it) ?

[lpcware]

Content originally posted in LPCWare by Jacquot on Thu Oct 23 07:36:04 MST 2014
Thank you for your fast answer, and thanks for the pointer !
I finally managed to make it work back again !
Just for the record, i don't know what made it work back but here's what I did:
- Follow the steps in your pointer [i.e. on the uEZGUI-1788-70WMV connect pins 3 and 4 on J1 [i.e. put the board in ISP mode]
- Flashed while holding this ISP mode
- Removed adaptive clocking and set the clock speed to something slow [100kHz i think]

It now works back as in the past.
Thanks !

[lpcware]

Content originally posted in LPCWare by LabRat on Thu Oct 23 04:27:12 MST 2014

---

Quote: Jacquot

- Tried to connect to the target using Flash Magic with no success

---

Switch to ISP and use FlashMagic...

http://www.lpcware.com/content/faq/lpcxpresso/regaining-debug-access

If that's not working, your chip is dead...