Hi,
I use FlashMagic 4.17.273; Target: LPC2378 chip; OSC = 12MHz;
When the Flash is cleared (done with the ULINK debugger) then it's no problem to enter ISP mode with Flashmagic to program the LPC2378.
But once programmed it's not possible to enter ISP mode again.
For example: to read the device ID FlashMagic says "operation failed to autobaud, step1". Osc shows that the chip isn't responding any more.
The code read protection location at 1FC is disabled (set to FFFFFFFF) in the programmed application.
I tryed to set OSC to 14.748 or 12Mhz, lowered the baudrate, increased the times T1 and T2 but no result until now. If someone knows what I'm doing wrong it would be great to know.
Kuno
Once you program a hex file Flash Magic places the interrupt vector checksum at location 14H. This causes the device to execute your firmware on reset rather than the bootloader. You need to reset the device while holding the ISP entry pin to place the device back into ISP mode. Check the user manual for exact details.
Andy
Hi Andy, thanks for your statement.
The IENIT0 Pin of the LPC2378 (that is used to set the device into ISP mode) is driven by RTS and IRESET is driven by DTR signals done with 2 transistors; I found this in the MCB2300 eval board drawings and made the same in my design. The bootloader version of LPC2378 is V3.2.
This morning when I powered up the whole stuff, I could read the device ID but minutes later the chip didn't respond again. Sometime it was possible to communicate and program the device, but I didn't find out what's wrong.
Sounds like there is an intermittent electrical problem.
Do you have the DTR/RTS option enabled in the Advanced Options in Flash Magic?
Next thing would be to put a scope on the reset and ISP entry pin to make sure that is working. After that check for glitches and ripple on the power supply, reset XTAL pins, etc.
Andy
Hi Andy,
yes, the DTR/RTS option is enabled. Also I monitored the TTL signals directly on the chip and didn't find strange things. FlashMagic applies the reset for some time while IEINT0 pin is set low, after T2 the communication starts, but in error case the chip gives no answer. When I had luck and the system runs the signals look like in error case but the chip will answer to FlashMagic tool. At this point all runs well.
So, now I will leave to the weekend, thanks an enyoy your weekend too. Kuno
Put your scope on the RxD pin of the device and make sure you see the bit pattern for a '?' each time you attempt to communicate with the device. If you do, put your scope on the TxD pin and make sure the bit pattern for an 'S' is always transmitted in response to the '?'. If not then the device is not in ISP mode for some reason.
Andy
Hi Andy,
I did what you said: The device seems not to be in ISP mode in error case.
But I can't see any difference when the system works except that the LPC2378 is responding when all runs well. The IEINT0 and RESET behaviour is identical in both cases.
This is very spooky, It seems to be a difference if the system powers up or only the RESET was active with all voltages already present. The POR (power on reset) seems to have some impact.
Do you have another device to test with? Are you letting the reset voltage drop to 0V during resets? Or something close to 0V?
Andy
Hi Andy,
yes, I tried another device and the behaviour was the same. But I found out something:
In my application I have a power fail circuit that uses the external interrupt 1. If this becomes active some parameters will be saved into the internal flash memory and normally after that the system dies. But for some reasons (when there only was a dropout for examle, or for testing) I use the watchdog to active shut down the whole system (same as when power was lost).
Now I take an completely erased hardware and the ISP FlashMagic tool works fine until I use this watchdog for the first time, after that I can't enter the boot loader mode again. Also after disconnecting the power for some minutes It's not possible to read the device ID.
The only way is to short the EINT0 pin for some seconds and then to short the reset pin. (that is exactly what the FlashMagic tool does, but there must be a difference I didn't see yet). At this time the flash holds the application program and FlashMagic is able to read the device ID for example.
It seems like the boot loader sees the watchdog flag and a valid application and starts the application.
Spooky, a reset doesn't clear this watchdog flag.
If I know more, I will tell you, it's an amazing problem.
Kuno
Interesting. I haven't come across a problem like this before. My only suggestion at this point is to contact your local NXP FAE for assistance. Sorry :(
Andy
Quote from: kunok on February 15, 2008, 10:21:32 AM
Hi Andy, thanks for your statement.
The IENIT0 Pin of the LPC2378 (that is used to set the device into ISP mode) is driven by RTS and IRESET is driven by DTR signals done with 2 transistors; I found this in the MCB2300 eval board drawings and made the same in my design. The bootloader version of LPC2378 is V3.2.
This morning when I powered up the whole stuff, I could read the device ID but minutes later the chip didn't respond again. Sometime it was possible to communicate and program the device, but I didn't find out what's wrong.
hi friend
he friend i m rahul from india
i want to use LPC2378 for one of my projects.
i m new to ARM.
i want to make an isp device for my LPC2378.
I want some circuit for that.
do u have any working circuit for that.
can u send me at my mail id: er_rahulkapoor@yahoo.co.in
.
also i want to ask one more thing. do we definitely need a bootloader for programming the arm. or it is only needed when we want to program it in c.I mean that is it possible to program arm in assembly language without bootloader
Go to http://www.keil.com/mcb2300/ and click on "Schematics" on the left for an example. Note that the circuit design is copyrighted, but perhaps it will give you inspiration.
The bootloader takes binary data and stores it in flash. It doesn't care what language was used to generate the data. It doesn't even have to be executable.
You can also program the device using JTAG or a parallel programmer.
Andy
Kuno -
Did you ever resolve this? This sounds very similar to a problem I'm having
with an LPC2103...although it does the "only program once" only when using
an FTDI USB-serial chip for the interface...when I use my standard tool, a
MAX232 and two transistors (I think we used the same circuit), it works fine.
See the thread elsewhere on this forum to catch up. I'd love to hear anything
that you resolved from NXP....I'm trying to talk to Andy here, an engineer at
FTDI, and NXP....but I suspect the problem is at the NXP end.
Thanks !!
Hi,
I have been having a similar problem with LPC2387 processors.
We have been using LPC2364, LPC2366 and LPC2368 for years with no problems, then when we started using the LPC2387 processor, we found we could only load the hex file the once, then loading afterwards is very intermittant. We have looked at scope traces when loading is successful and unsuccessful and we can't see any differences.
Have you any suggestions on the cause of this.
Thanks in advance.
Barny
Did you put your scope on the reset and ISP entry pin? Correct waveform shape and timing is needed to enter ISP mode. If you have a new board design for the LPC2387 then I would suspect that first.
Andy
Hi Andy,
Thank you so much for your help.
Yes we put a scope on the ISP and RST pins and could see the correct timing.
The board is an old design, we have 3 different designs which were all using the 2368 processor, then we decided to upgrade to the 2387, (2368 and 2387 pin compatiable), The boards ran fine with the new 2387 processor, but then when we wanted to do an upgrade of firmware we couldn't download.
We found that we can download to a fresh processor but after that we can't download, we also found that if we then cleared the processor memory using JTAG we can then download.
We will do some more investigation and let you know if we find anything, if you have any new ideas that would be great.
Thanks
ISP can be disabled by programming a specific value at location 0x000002FC. This is called "CRP" in the NXP user manual for the device. Are you making sure you are reserving this location in your project and not accidentally putting one of the magic numbers there?
Andy
Hi Andy,
Yes we checked this and we are not putting anything in this location.
Just to keep you posted, we set up a simply test (Flash Magic was NOT part of the test).
The test had a simple program and a reset circuit, the RST pulled to 3.3v through a 47K and a switch to ov.
We ran this test on a range of processors, LPC2364, LPC2366, LPC2368 and LPC2387.
We found that only the LPC2387 would not reset externally and more so, only revision D of the LPC2387 processor.
This suggests that the problem is in the LPC2387 processors. Are you aware of any issues with LPC2387 Revision D processors.
Also with Flash Magic you can read the boot loader version in the processor, we found that versions 3.3 and below and everything was OK. 3.4 boot loader was on the processors with the problem.
Any feedback would be appreciated.
Thanks
Barny
Thanks for the detailed testing. Unfortunately we don't know anything about the internal details of the bootloader - only NXP will be able to answer your questions.
Andy
Hi Andy,
I have been doing some investigation with the LPC2387 processor (i know other people have experienced problems with the PLC2364, LPC2368 and LPC2378). I found that when you download to a fresh device it downloads OK, but when you download again after a power cycle it will not download. The problem appears to be the actual reset of the processor as i found that when i try and reset the processor by connecting the rst line to 0v nothing happens.
I found the solution to the problem was to turn the ISP line on for about 1 second before doing a download then do a download in the normal way.
Is there some where in the configuration of flash magic where you can set ISP delay, if not is it possible you can do an update to the driver so the ISP line turns on 1 second or more before turning the reset line on then doing a download. IF it is possible and you would like me to test it for you let me know.
Thanks
Barny
It's hard for me to understand exactly what you mean. Please see the diagrams for DTR/RTS on pages 49 and 50 of the manual. You can control how long the ISP pin is pulled low before ISP starts by setting the values of T1 and T2 in the advanced options.
If you are talking about something else can you please post your own version of those diagrams so I can better understand where the one second needs to be?
Thanks, Andy
HI Andy,
Find attached a basic timing diagram.
Basically Flash Magic works OK when the ISP line is turned on 1 second or longer before turning the RST line on. The ISP line is kept on during the whole of the download.
I hope this helps.
Thanks Barny
Next release will have a hard-coded delay of 1.2s at this point. When it is released please check with a scope and report back on if the problem you are seeing is solved.
Andy
That's great, thank you so much. I will check it once it has been released.
Do you have an approx release date, so i can make some time available.
Thanks
Friday.
Hi Andy,
Can you advise me whether Version 8.82 has the changes as above. If so is there any setting etc i need to do?
Thanks for you help.
Barny
Yes it does. No settings to change.
Dear Andy,
Unfortunately i couldn't get it to work. I tried various settings but still had no luck.
Find attached the scope trace i took.
I would expect the ISP line to be low for 1.2 seconds before any action from the RST line and the ISP line to stay low during the whole download period.
Thanks
Barny
Here is the test I just performed with the current version of Flash Magic (8.95).
Keil MCB2300 board populated with a LPC2388.
Genuine FTDI USB to RS232 cable
FM advanced settings:
- Use DTR and RTS to control RST and ISP pin
- Keep RTS asserted while COM port open
- T1 = 300ms, T2 = 300ms
Everything else is unchecked.
Note: I do see a bug in FM: checking "Keep RTS asserted..." and clicking OK *does* work but the next time the dialog is opened it is unchecked again. We will fix that. It doesn't affect this test.
Scope with channel A = RST pin, channel B = P2.10 pin. Note - the scope is connected to the pins on the microcontroller.
Waveform is attached. Blue = channel A = RST.
I've made a measurement from the trigger point to the dotted line. As you can see it is 1.2 seconds, as expected.
Analysis:
RST is lowered
1.2s later P2.10 is lowered
300ms later RST is raised, device is now in ISP mode
P2.10 remains low because we selected that option in FM
At end of ISP operation RST is lowered
300ms later P2.10 is raised
300ms later RST is raised, device is now executing
So from this I don't see any issues with the way it is working.
If you are getting something drastically different then I would first suspect the USB to RS232 cable you are using (if you are using one).
Andy
Dear Andy,
Thanks for that information. Unfortunately i have been struggling to get it to work after the settings you suggested.
The USB to RS232 converter I am using is a ULINX device which I use on alot on equipment, i paid £200+ for it, i know it is a good one.
See attached image 'FlashMagic-1' The blue line is ISP, the red line is RST. Maybe the blip at the start on the RST line is the cause of the problem. These traces are at the LPC2387 pins.
Set attached 'FlashMagic-2' when i used the real RS232 of the PC. The trace is totally different.
One thing i did find now with both comm ports (USB-RS232 and Genuine RS232 port) is that if the ISP line is low all the time (basically i shorted this pin to Ov), both comm ports work successfully with Flash Magic.
Is it possible to set ISP line always low?
Sorry to be a pain... i do know this problem is down to the actual LPC23xx micro-processor because i can't even it to reset when i short the pin to 0vdc.
Thanks for your support so far.
Barny
No it is not possible for the ISP line to always be low. This is because FM has no control over that signal before the COM port is opened and after it is closed.
If that signal needs to be low all the time then why connect it to your RS232 cable? However in general the ISP pin P2.10 shouldn't need to be low all the time and this indicates to me that there might be a hardware issue.
The fact that the trace is different when using a built-in COM port or a USB to RS232 converter is a concern. From the FM point of view this is a black box. A call is made to Windows to open the COM port and then further calls are made to Windows to set the states of DTR and RTS. What the COM port driver does with those commands is not known.
In general the waveforms I posted match the intention of the software design. This is using one of the low-cost US232R-100 cables:
http://www.ftdichip.com/Products/Cables/USBRS232.htm
I would suggest as a next step to try one of these.
Andy
Dear Andy,
Thanks for that info.
From the testing i have done it appears the problem is with the actual reset of the processor.
I will order a USB to RS232 converter as per your suggestion.
Thank you for your support.
Barny