How to restore NXP default bootloader with ICP

kittmaster · August 31, 2009, 02:22:22 PM

is it possible? I have four chips that are bricked in ISP. I can communicate with it via ICP with ISP protect active. I believe the bootloader is damaged, where do I get the hex file to restore it? The resource page only has asm file and needs to be compiled into a working project. I'm just looking to restore the device to factory defaults and condition. Is this possible via ICP?

Last post on this topic was 2006, so any new info on how to fix a dead ISP chip?

Thanks

frank · August 31, 2009, 09:03:55 PM

You need to compile one of these asm source code(select a correct version code according to AN10337) to an executable image, then download this image to your MCU with an ICP or PP tool.

kittmaster · September 01, 2009, 06:32:11 AM

that's odd, because I added the source to an existing working project, and it still came up as a brick in ISP mode. I'll try to compile the asm solo and just flash that via ICP and see if that solves the problem......thanks

Jan Waclawek · September 02, 2009, 04:39:35 AM

Depending on how do you define "brick", you might also want to set the boot status bit (BSB) in Boot status register, and the Boot Vector, to their appropriate "factory default" values.

JW

kittmaster · September 02, 2009, 05:46:40 AM

LOL, it will let me do everything, get device sig, blank check etc etc. It just won't communicate via ISP. I have two board sets, one is an ICP programmer with PLCC socket for ICP programming, and then their is the application board that is purely ISP. So I can put the chip into the ICP tool, and program it, put it in app board, and the program via ICP runs and does what it supposed to. Try to put in into ISP mode, flashmagic times out and say it can communicate with it.

Someone sent me a bootloader file, I'll disable protect ISP and program it via ICP with ISP protect off and if it does what I expect, that flash should restore the ISP bootloader?

?

Thats the theory anyway. Hopefully will work as I expect it too.

Andy Ayre · September 02, 2009, 09:12:11 AM

What happened to corrupt the bootloader? Perhaps it also corrupted some factory settings somewhere in the device? Bottom line is that I probably wouldn't trust those devices now, and just get new ones.

Andy

kittmaster · September 02, 2009, 09:41:57 AM

Andy,

I was using a wall wart to power the application board, with other devices consuming power, I believe it browned out during programming due to the lack of current from the wall wart (it was toasty when I realized what was going on). I moved to a new house, so I couldn't find my power supply, after I did find it, it programs normally and both methods work. So I believe the wall wart was the issue at hand and not the hardware.

This is more of a practical exercise for me to see if I can restore them and have a way to repair in the field if something like this arises again and have a solution to avoid shipping a board back.

Andy Ayre · September 02, 2009, 09:52:38 AM

I think the problem is that there are a lot of ways for a microcontroller to fail, but the symptoms may be the same. So even if you manage to get these devices working, a failure in the field may look the same but actually be a different problem.

It seems your devices are socketed, so perhaps a worst-case solution to a failure in the field is to program a new device and send just the new device out to be swapped. Plus combine that with enhanced brownout detection, etc. to avoid it happening.

Andy