Author Topic: Debugging ISP Problems  (Read 29793 times)

Andy Ayre

  • ESAcademy Staff
  • Sr. Member
  • *****
  • Posts: 2099
    • View Profile
    • Embedded Systems Academy, Inc.
    • Email
Debugging ISP Problems
« on: January 24, 2007, 06:58:36 pm »
These are the steps to go through when ISP does not work. Some are device specific and are indicated with [<devicename>] before the item. For example, [LPC9xx]. This list will be added to over time based on discussions in the forums.

By completing these steps and posting the results that you get and the checks that you have performed in the forums when posting your problem, it will be quicker and easier for others to provide suggestions or even answers.

1. Ensure the crystal frequency entered is accurate. For example, if you are using 11.0592MHz, then enter 11.0592, not 11.0000 or 11.

2. If you are using high-speed communications mode with the correct frequency entered, then try connecting with the feature turned off. Make sure the device is reset again into ISP mode if needed before attempting to connect.

3. If you have the half-duplex communications feature turned on and you do not need it, then turn it off. It only slows down the serial communications.

4. If you are using a baud rate higher than 9600, lower it to 9600, reset the device into ISP mode (if applicable) and try again. The baud rate at which you are able to successfully connect to the device depends on which device you are using, the crystal frequency you are using and how many clocks per cycle the device is configured for.

5. If you are already using 9600 baud, or lowering to 9600 baud does not work, then try 4800 baud. If your crystal frequency is 6MHz or below, try the baud rates below 4800 baud.

6. Ensure you have the correct device selected in Flash Magic. Some of the devices have very similar names. If you change the device then ensure you reset the device into ISP mode if applicable before trying again.

7. Ensure the COM Port selected in Flash Magic is the correct one you are using.

8. Check the datasheet and Philips Application Note AN461 for details of the requirements to place the device into ISP mode using hardware methods. Ensure the voltages on the necessary pins are at the expected levels.

9. Ensure the power supply to the device is stable, within the allowed range, and free from glitches.

10. Ensure your ground is stable and it is not floating. A floating ground will cause devices to behave erratically or incorrectly.

11. [89C51Rx2Hxx, 89C66x] Ensure P2.6 and P2.7 are pulled high during reset into ISP mode.

12. [LPC9xx] If the Keil MCB900 board is being used, then ensure the power is removed and reapplied after changing the jumpers. Failure to do this could cause the device to enter an unknown state.

13. Try connecting to the device using Hyperterminal or any other terminal program, such as Tera Term Pro. Hyperterminal comes with most versions of Windows and is usually available from the Start Menu, under Start | Programs | Accessories | Communications. If it does not appear on the Start Menu, then you may need to install it. The method to do this varies between different versions of Windows, but in general:

Click on Start | Settings | Control Panel
Choose Add/Remove Programs
Click on Windows Components or similar
Search for the checkbox for Hyerterminal and check it. You may need to keep selecting categories and clicking on the Details button to view more choices.

Once you have a terminal program running, select the COM Port you are using and create a connection with the following configuration:

8 bits
No parity
One stop bit
No handshaking or flow control
9600 baud or 4800 baud
No local echo (if available)

If you are using the Start BootROM feature, then send the Start BootROM command your device expects. If the command and/or the full stop response are not echoed back, then the problem potentially lies in your application code.


Reset the device into ISP mode if applicable.
Send a single uppercase U ('?' for LPC2xxx devices)

If the device fails to echo the uppercase U (or '?') back to the terminal program then there is a COM Port, serial cable or device problem.

14. check using an oscilloscope:

For LPC2xxx devices a '?' is used instead of a 'U'.

If the U is not arriving at the RxD pin of the device then it is a COM Port or serial cable problem.
If the U is arriving, but no U is leaving the TxD pin in response, then the device is not executing the bootloader for some reason. Check how you are placing the device into ISP mode.
If the U is leaving the TxD pin of the device but not arriving at the terminal program, then it is a COM port or serial cable problem.
If the baud rate of the U is not the baud rate selected in the terminal program, then either the PC COM port is faulty, or there is something like opto-isolators affecting the baud rate.

If the device echoes back the U to the terminal program then try sending some ISP commands to the device and seeing if they are echoed back. If any response from the device takes longer than about 10 seconds, then perform the Last Resort steps below.

If the device echoes back the U and all ISP commands and responses then the problem likely lies in Flash Magic somewhere.

15. try using a different device, different COM Port or different PC, with a different version of Windows.

16. If you are using the COM Port control signals DTR and RTS to place the device into ISP mode, look at the signals on an oscilloscope and compare them with the waveforms shown in Flash Magic Application Note 1. If there are differences, check your circuit.

Ensure the timing for T1 is at least 50ms and T2 is at least 100ms. Try increasing both values to 200ms and 300ms respectively.

Try temporarily using switches or jumpers to place the device into ISP mode, rather than using DTR and RTS. Turn off the option in Flash Magic to use DTR and RTS.

17. Another cause of problems could be that your device is taking a little longer to respond than Flash Magic allows. This problem has been most frequently observed during device erasing or when using some types of USB to RS232 converters or cables.

To increase the timeouts in Flash Magic go to the Options menu, choose Advanced Options and click on the Timeouts tab. Check "Use my timeouts for ISP operations" and increase the values displayed in the boxes. Keep increasing the timeouts one or two seconds at a time and retesting.

Note that increasing the timeouts has the downside that if something should go wrong during an ISP operation, or if you start Flash Magic with no device connected, then you will have a longer wait before Flash Magic gives up trying.
« Last Edit: March 09, 2007, 11:13:22 am by Andy Ayre »
Embedded Systems Academy, Inc.
support at esacademy dot com

Jan Waclawek

  • Full Member
  • ***
  • Posts: 220
    • View Profile
    • EFTON homepage
Re: Debugging ISP Problems
« Reply #1 on: January 29, 2007, 09:56:19 am »
Great post! - where are the markings on this forum to give it an "Excellent"? :-)

Only a few comments.

I would be a bit more specific with 10. - "ensure common ground between MCU's RS232 converter and PC ground is present - a broken GND in cable is a pain in ***"

Before checking for U on oscilloscope etc., a simpler/faster way is to remove the chip (if socketed) and short Rx/Tx at the socket (if it's a "classic" quasibidirectional '51 output, it can be shorted without removing the chip but this might not be true for the LPC's, I don't know) - any character should be echoed (and if short removed, the echo should cease). A "local echo" in the terminal switched on should exhibit double-echoed characters during the short.

If the echo from the device is present but different from "U", don't panic, reset (switch off/on power) the micro and retry - you might need to repeat it several times (I'd give it up and go for troubleshooting after 5-6 attempts (at a reasonably low speed - say 2400)). This is the same when the "decrease speed" window in FM appears. Due to how the autobauding works, chances are, that it autobauds to a slightly different speed than expected. <shameless advertisement>There is an excel chart on my pages calculating the probability of an autobaud going wrong for different crystal, baudrate and assymetry on the cable/converter. </shameless advertisement>

I would also add two device specific hints, although by the time one reads this it might be late...:

[P89V51RD2] - double check you have not selected P89C51RD2 by mistake - in case you did, you might be in softice mode, <shameless advertisement>google for unsoftice </shameless advertisement>

[P89C51RD2] - if you specified full chip erase, be patient until it finishes - this might take looooong (say, 30 seconds). If you disconnect power meantime, you'll most probably end up with the "bootvector lost" problem.

Finally one request.
Item 17 says that in case of long timeouts and something goes wrong, FM might "freeze". Wouldn't it be possible to come out of this "freeze", e.g. using Ctrl-C or similar?

Andy Ayre

  • ESAcademy Staff
  • Sr. Member
  • *****
  • Posts: 2099
    • View Profile
    • Embedded Systems Academy, Inc.
    • Email
Re: Debugging ISP Problems
« Reply #2 on: May 18, 2007, 04:39:26 pm »
From Joe Goldburg regarding the P89(L)V51Rx2:

Using an 11.0592MHz Xtal --  On Power up the P89V51 looks down the RxD line for a 'U' Character ONLY for 400mS

So you need have a reset circuit coupled with flash magic OR hold down the uppercase 'U' key in a terminal program like hyperterminal.

For direct PC - Hardware control
Set flashmagic --> Advanced Options --> Hardware config --> Use DTR to control RST.
Embedded Systems Academy, Inc.
support at esacademy dot com