Author Topic: Re-programming of P89LPC936 FDH fails  (Read 8999 times)

Johnny

  • Jr. Member
  • **
  • Posts: 3
    • View Profile
Re-programming of P89LPC936 FDH fails
« on: October 31, 2005, 12:47:37 am »
Hello!

I was able to read the device signature of the P89LPC936FDH (the response was 24H) and perform the blank check without any problems. After programming the device with a test software (it was Keil's blinky.hex file) the blinky program works as expected (full success). However I cannot re-program the device by no means with the "real" HEX file now nor does it respond any more to read requests from Flash Magic.

In order to avoid a mistake and as the the P89LPC936FDH is already rock-solid glued on the target board I tested the methodology of programming with both, the LPC932BA and the LPC935FA a hundred times successfully. After that careful examination I gave it a try: Now the P89LPC936 is blocked. I get "unable to connect at the specified baud rate ...

For further information: FM version 2.44, tried all BR 7200 kB/s down to 2400 kB/s,
"Erase all Flash" and "Erase blocks used by Hex File" was unchecked. And for sure I kept my fingers away from the Flash Magic ISP "Boot Vector and Status Bit" drop down menu.
Hardware environment: Original Keil MCB 900 board with 15 cm long wires from the 28-pins socket to the target Micro pins. Settings of T1: 250 ms and T2 120 ms. Measured VDD rise and fall times at the Micro: 0.05/0.35 ms. The digital signals Reset, TXD and RXD seem to be un-corrupted and without oscillations.

Have I killed the Micro? All assistance welcome. Please help!

Thanks,

Johnny


erikm

  • Guest
Re: Re-programming of P89LPC936 FDH fails
« Reply #1 on: October 31, 2005, 06:10:44 am »
first time, but not next time indicates one and only one thing:

Since the chips arrive in ISP mode, they will program the first time even with a faulty "kick into ISP" circuit.

Erik

Andy Ayre

  • ESAcademy Staff
  • Sr. Member
  • *****
  • Posts: 2160
    • View Profile
    • Embedded Systems Academy, Inc.
    • Email
Re: Re-programming of P89LPC936 FDH fails
« Reply #2 on: October 31, 2005, 06:24:59 am »
Did you test the 932 and 935 using the same target hardware as the 936 is using? If not then the difference might be there. Perhaps bad solder joint somewhere?

Did you accidentally program the 936 with the 932 or 935 selected in Flash Magic? If so then you might have programmed the wrong boot vector into the device, because it can vary between LPC9xx devices. However, by default (i.e. unless you turned it off) Flash Magic will warn you first that the device you have selected does not match.

Embedded Systems Academy, Inc.
support at esacademy dot com

Johnny

  • Jr. Member
  • **
  • Posts: 3
    • View Profile
Re: Re-programming of P89LPC936 FDH fails
« Reply #3 on: October 31, 2005, 08:45:39 am »
Hardware review: I used exactly the same hardware for testing and programming. The LPC932s and the LPC935s were placed into the PLCC socket on the MCB 900 board first AND and in the second step into a PLCC socket at the end of a 12 cm long 10-wire flat ribbon cable. It's the same connection cable. Between the three digital signals is always one wire grounded to reduce crosstalk. As far as I can see: there is - in electrical view - no difference between the circuits.

Testing prior to programming: I have made every effort and double-checked all steps to avoid disturbances, as I know it's really difficult to replace the SMD device here. I did not accidently mix the devices up and I do not ignore warnings because of the importance of the project.
As you mentioned, Andy, I "overprogrammed" an LPC932 in the LPC936 settings with a 12kB HEX file. As expected, that device is no longer responding, and I intend to re-program it with my Keil EPM900 emulator/parallel programmer some times later.

I worked on the MCB 900 board and improved the VDD rise and fall times to less than 10 micro-seconds by adding an NPN Transistor (the emitter to ground) in parallel to the PNP device. All unused pins at the 28 pins socket are connected to VDD with 33KOhms in parallel with 470pF and the flickering of the eight LEDs has stopped.

The test devices are working any time. But still no luck with the LPC936.

I am wide open for every advise and all questions pushing me in the right direction. Thank you in advance !

Johnny


Andy Ayre

  • ESAcademy Staff
  • Sr. Member
  • *****
  • Posts: 2160
    • View Profile
    • Embedded Systems Academy, Inc.
    • Email
Re: Re-programming of P89LPC936 FDH fails
« Reply #4 on: October 31, 2005, 09:22:55 am »
OK, try this, although I doubt it will tell me much.

Start FM
Press F1 to enter Debug mode ([Debug] appears at the top)
Choose read device signature from the ISP menu and wait for the error
Press F2 to exit debug mode.
Email me the debug file C:\flashmagic.fmd
Delete the debug file.

My email address is at the bottom of this post and in the Help About window of FM.

Embedded Systems Academy, Inc.
support at esacademy dot com

Johnny

  • Jr. Member
  • **
  • Posts: 3
    • View Profile
Re: Re-programming of P89LPC936 FDH fails
« Reply #5 on: November 02, 2005, 09:37:33 pm »
Dear Andy ,

Thanks a Million for your help. Programming of LPC936 is like a charm.

It required only one READ DEVICE SIGNATURE push in the DEBUG mode and the LPC936 is again open to enter ISP.

Can you please confirm or correct me from wrong:

Refering to the P89LPC933/.../936 Datasheet Rev. 06 as of 20 June 2005 Fig 31 says:
Maintain at minimum waiting time of 50 microseconds before applying RST pulses. But the maximum is infinite. I understand, the Device should wait forever in order to detect the pulses.

My experience is that all five consecutively tested PLC936s give up after T1 = 220 ms. If I change in FlashMagic the default settings for LPC932 ... LPC936 for T1 (250ms) and T2 (120ms) to any lower value than 220 ms down to 1 ms entering ISP and programming works perfectly right from the beginning.

Thank you,

Johnny


Andy Ayre

  • ESAcademy Staff
  • Sr. Member
  • *****
  • Posts: 2160
    • View Profile
    • Embedded Systems Academy, Inc.
    • Email
Re: Re-programming of P89LPC936 FDH fails
« Reply #6 on: November 03, 2005, 07:09:52 am »
I'm not sure why reading the device signature helped - but if it worked that is great.

Your observation of the effect T1 has on ISP entry is interesting. I have never had a problem myself with 250ms, but we will potentially lower the default if it turns out to be a problem for a number of users. Thanks.

Embedded Systems Academy, Inc.
support at esacademy dot com

sbjoshi

  • Jr. Member
  • **
  • Posts: 1
    • View Profile
    • Email
Re: Re-programming of P89LPC936 FDH fails
« Reply #7 on: May 20, 2010, 12:13:11 pm »
Sender: S B Joshi

We recently (May 2010) faced same problem (of P89LPC936 programming only once and then not entering ISP mode again).

I will try your solution of entering debug mode using F1 key and then try kickstart ISP by asking for signature. I hope it will work.

To be on safer side, we have added a UART based command (to our application code) to facilitate setting the Boot Status Bit by using "89LPC935 - Boot Loader activation by software" application note authored by "R Raghunathan / 12 July 2009" based on "original idea by Erik Malund and initial assembly implementation by Lex Timmerman.". It worked for us very well and it enables graceful entry to ISP mode, overriding the 3 reset pulse ckt of MCB900. We have added some code to restore boot vector to 0x3F, in case it is not read as 0x3F.

Reporting a new issue with LPC936 as below:

We also observed that if external reset pin is disabled using FlashMagic then neither ISP runs, nor, my application code runs. The P89LPC936 enters erratic mode and keeps echoing odd characters to whatever I type in Hyperterminal at 9600 baud. Can anyone help us for this, please.

Thanks in Advance.

Suresh Joshi