Hi All- I'm currently experiencing a very frustrating issue with the LPC2138 bootloader. I can successfully and reliably use the Philips flash utility to download an image to a blank LPC2138 once and only once. After that, the flash utility is never able to communicate with the LPC2138. I have been monitoring the recent bootloader thread that was resolved by manipulating the watchdog overflow flag which, if set, will cause the bootloader reques to be ignored. Unfortunately, this is not the same problem I am having because I'm never enabling the watchdog. I've been working with an evaluation board for 6 months now so I felt confident I understood the processor because I never had this issue. Now that I am bringing up custom hardware, I removed everything from the board except the processor, JTAG, and power supplies. I thought perhaps my code was inadvertently configuring an I/O pin in conflict, so I modified the application code to simply sit in a loop after disabling interrupts and other basic init steps. The signals to the processor are exactly what I would expect: 1.) The reset line and P0.14 are pulled low by the Philips Flash application at t=0. 2.) The P0.14 line is held low for about 470mS before being released, and the reset is held low for about 820mS before being released. 3.) After these transitions, the processor sees the 0x3F being transmitted by the flash utility. So, as far as I can tell, everything is ocuring correctly, but I am unable to access the bootloader after the first initial image download. I was initially swapping processors, but each one behaves the same way. Thanks- Tim

LPC2138 Bootloader Issue
Started by ●March 1, 2006
Reply by ●March 1, 20062006-03-01
tah2k wrote: > Hi All- > > I'm currently experiencing a very frustrating issue with the LPC2138 > bootloader. I can successfully and reliably use the Philips flash > utility to download an image to a blank LPC2138 once and only once. > After that, the flash utility is never able to communicate with the > LPC2138. > > I have been monitoring the recent bootloader thread that was > resolved by manipulating the watchdog overflow flag which, if set, > will cause the bootloader reques to be ignored. Unfortunately, this > is not the same problem I am having because I'm never enabling the > watchdog. > > I've been working with an evaluation board for 6 months now so I > felt confident I understood the processor because I never had this > issue. Now that I am bringing up custom hardware, I removed > everything from the board except the processor, JTAG, and power > supplies. I thought perhaps my code was inadvertently configuring an > I/O pin in conflict, so I modified the application code to simply > sit in a loop after disabling interrupts and other basic init steps. > > The signals to the processor are exactly what I would expect: > 1.) The reset line and P0.14 are pulled low by the Philips Flash > application at t=0. > 2.) The P0.14 line is held low for about 470mS before being > released, and the reset is held low for about 820mS before being > released. > 3.) After these transitions, the processor sees the 0x3F being > transmitted by the flash utility. > > So, as far as I can tell, everything is ocuring correctly, but I am > unable to access the bootloader after the first initial image > download. I was initially swapping processors, but each one behaves > the same way. > > Thanks- > Tim > Hello Tim, I think I know your problem. You are writing that (from t0 on) P0.14 is released after 470ms and /Reset after 820ms? That's simple to explain! Here is a small flow of what will happen after reset: * /Reset is going high * LPC enters bootloader (vector-table located in boot flash; see manual) * bootloader is checking P0.14: if (P0.14 is high) { goto bootloader_shell /* wait for communication with flash-utility */ } else { /* check if for valid checksum of user-vector-table */ if (checksum is OK) goto reset-vector-at-user-table /* jump to your code (user-vector-table at 0x00000000) */ else goto bootloader_shell /* wait for communication with falsh-utility */ } That means P0.14 must be held down as long as the bootloader has checked this pin. The reason why you can programm your LPC only the first time is checking of user-vector-table's checksum. If you have blank device this checksum is invalid. In this case the bootloader remains in bootloader state. Keep in mind that P0.14 is a simple GPIO pin and LPC's bootloader is still a piece of code. There is nothing magic. You can talk with your bootloader by hand too. Just open a serial terminal program; enter bootloader mode on LPC (P0.14, /Reset) and type '?' until LPC returns "Syncronized" (Auto-baudrate detection). After that you must reply this with the string "Synchronized<CR>" too. Then you can enter bootloader commands decribed in manual. If you want you can download my open-source flash utility (see below) and use the secrete option "-vvv" for debugging. Sten -- /************************************************ Do you need a tiny and efficient real time operating system (RTOS) with a preemtive multitasking for LPC2000 or AT91SAM7? http://nanortos.net-attack.de/ Or some open-source tools and code for LPC2000? http://www.net-attack.de/ ************************************************/
Reply by ●March 1, 20062006-03-01
Hi Tim,
I haven't checked this on my own hardware, but it sounds to me like
you have RESET and P0.14 swapped over.
The bootloader can only look at P0.14 after RESET has been released.
So I would expect P0.14 to be asserted (low) for longer than RESET.
Hope this helps,
Danish
--- In lpc2000@lpc2..., "tah2k" <tah2k@...> wrote:
> I'm currently experiencing a very frustrating
issue with the LPC2138
> bootloader. I can successfully and reliably use the Philips flash
> utility to download an image to a blank LPC2138 once and only once.
> After that, the flash utility is never able to communicate with the
> LPC2138.
>
> I have been monitoring the recent bootloader thread that was
> resolved by manipulating the watchdog overflow flag which, if set,
> will cause the bootloader reques to be ignored. Unfortunately, this
> is not the same problem I am having because I'm never enabling the
> watchdog.
>
> I've been working with an evaluation board for 6 months now so I
> felt confident I understood the processor because I never had this
> issue. Now that I am bringing up custom hardware, I removed
> everything from the board except the processor, JTAG, and power
> supplies. I thought perhaps my code was inadvertently configuring an
> I/O pin in conflict, so I modified the application code to simply
> sit in a loop after disabling interrupts and other basic init steps.
>
> The signals to the processor are exactly what I would expect:
> 1.) The reset line and P0.14 are pulled low by the Philips Flash
> application at t=0.
> 2.) The P0.14 line is held low for about 470mS before being
> released, and the reset is held low for about 820mS before being
> released.
> 3.) After these transitions, the processor sees the 0x3F being
> transmitted by the flash utility.
>
> So, as far as I can tell, everything is ocuring correctly, but I am
> unable to access the bootloader after the first initial image
> download. I was initially swapping processors, but each one behaves
> the same way.
Reply by ●March 1, 20062006-03-01
Quoting tah2k <tah2k@tah2...>: > The signals to the processor are exactly what I would expect: > 1.) The reset line and P0.14 are pulled low by the Philips Flash > application at t=0. > 2.) The P0.14 line is held low for about 470mS before being > released, and the reset is held low for about 820mS before being > released. > 3.) After these transitions, the processor sees the 0x3F being > transmitted by the flash utility. That sounds like the reset and P0.14 lines are reversed. P0.14 must be low coming out of reset. Something like Reset ---|____________|--------------- P0.14 ---|______________________|---------- Actually there's no need for P0.14 to go high until you are done but it won't hurt either way. See http://www.aeolusdevelopment.com/Articles/InSystemProgramming.html and http://www.open-research.org.uk/ARMuC/index.cgi?Standard_ISP_Header for some discussion on how to do this with a standard ISP header. Robert
Reply by ●March 1, 20062006-03-01
Thanks, you are correct and the problem is solved. I have been looking at those two lines for days knowing what they 'should' be. Kills me. Thanks- Tim --- In lpc2000@lpc2..., Robert Adsett <subscriptions@...> wrote: > > Quoting tah2k <tah2k@...>: > > > The signals to the processor are exactly what I would expect: > > 1.) The reset line and P0.14 are pulled low by the Philips Flash > > application at t=0. > > 2.) The P0.14 line is held low for about 470mS before being > > released, and the reset is held low for about 820mS before being > > released. > > 3.) After these transitions, the processor sees the 0x3F being > > transmitted by the flash utility. > > That sounds like the reset and P0.14 lines are reversed. P0.14 must be low > coming out of reset. Something like > > Reset ---|____________|--------------- > > P0.14 ---|______________________|---------- > > Actually there's no need for P0.14 to go high until you are done but it won't > hurt either way. > > See http://www.aeolusdevelopment.com/Articles/InSystemProgramming.html and > http://www.open-research.org.uk/ARMuC/index.cgi? Standard_ISP_Header for some > discussion on how to do this with a standard ISP header. > > Robert >
Reply by ●March 1, 20062006-03-01
Tim, >> 2.) The P0.14 line is held low for about 470mS before being >> released, and the reset is held low for about 820mS before being >> released. Is it correct that P0.14 is high after reset in the sequence that you outlined ? I believe that you need to insure that P0.14 is low for greater than 3mS after reset has been released to enter the bootloader. I am pretty new to the LPC so I hope this helps, Bryce tah2k wrote: > Hi All- > > I'm currently experiencing a very frustrating issue with the LPC2138 > bootloader. I can successfully and reliably use the Philips flash > utility to download an image to a blank LPC2138 once and only once. > After that, the flash utility is never able to communicate with the > LPC2138. > > I have been monitoring the recent bootloader thread that was > resolved by manipulating the watchdog overflow flag which, if set, > will cause the bootloader reques to be ignored. Unfortunately, this > is not the same problem I am having because I'm never enabling the > watchdog. > > I've been working with an evaluation board for 6 months now so I > felt confident I understood the processor because I never had this > issue. Now that I am bringing up custom hardware, I removed > everything from the board except the processor, JTAG, and power > supplies. I thought perhaps my code was inadvertently configuring an > I/O pin in conflict, so I modified the application code to simply > sit in a loop after disabling interrupts and other basic init steps. > > The signals to the processor are exactly what I would expect: > 1.) The reset line and P0.14 are pulled low by the Philips Flash > application at t=0. > 2.) The P0.14 line is held low for about 470mS before being > released, and the reset is held low for about 820mS before being > released. > 3.) After these transitions, the processor sees the 0x3F being > transmitted by the flash utility. > > So, as far as I can tell, everything is ocuring correctly, but I am > unable to access the bootloader after the first initial image > download. I was initially swapping processors, but each one behaves > the same way. > > Thanks- > Tim > > > > > > > SPONSORED LINKS > Microcontrollers > <http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=mfaAujKZXA2Z_vxre9sGnQ> > Microprocessor > <http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=9jjd2D3GOLIESVQssLmLsA> > Intel microprocessors > <http://groups.yahoo.com/gads?t=ms&k=Intel+microprocessors&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=OMnZuqMZX95mgutt4B-tDw> > > Pic microcontrollers > <http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&w4=Pic+microcontrollers&c=4&s&.sig=Malspbd0T4Rq3M4Q0nHrfw> > > > > > >. > > > > -- Bryce Himebaugh Design Engineer Indiana University Computer Science Dept. (812) 855-6984 http://www.cs.indiana.edu/~bhimebau/
Reply by ●March 17, 20062006-03-17
--- In lpc2000@lpc2..., Sten <list@...> wrote: > > tah2k wrote: > > Hi All- > > > > I'm currently experiencing a very frustrating issue with the LPC2138 > > bootloader. I can successfully and reliably use the Philips flash > > utility to download an image to a blank LPC2138 once and only once. > > After that, the flash utility is never able to communicate with the > > LPC2138. > > > > I have been monitoring the recent bootloader thread that was > > resolved by manipulating the watchdog overflow flag which, if set, > > will cause the bootloader reques to be ignored. Unfortunately, this > > is not the same problem I am having because I'm never enabling the > > watchdog. > > > > I've been working with an evaluation board for 6 months now so I > > felt confident I understood the processor because I never had this > > issue. Now that I am bringing up custom hardware, I removed > > everything from the board except the processor, JTAG, and power > > supplies. I thought perhaps my code was inadvertently configuring an > > I/O pin in conflict, so I modified the application code to simply > > sit in a loop after disabling interrupts and other basic init steps. > > > > The signals to the processor are exactly what I would expect: > > 1.) The reset line and P0.14 are pulled low by the Philips Flash > > application at t=0. > > 2.) The P0.14 line is held low for about 470mS before being > > released, and the reset is held low for about 820mS before being > > released. > > 3.) After these transitions, the processor sees the 0x3F being > > transmitted by the flash utility. > > > > So, as far as I can tell, everything is ocuring correctly, but I am > > unable to access the bootloader after the first initial image > > download. I was initially swapping processors, but each one behaves > > the same way. > > > > Thanks- > > Tim > > > Hello Tim. As long as the Philips flash utility can drive the \RESET and P0.14 with DTR and RTS there should be no problem with the bootloader. -Sergei
