Lpc2000

Dear all,
 
  So, I've done some more trying, used a different USB->Serial converter and
the same problem.

  Then I tried something else, the .hex file that comes with the S1(S2 or
S3) example, and guess what, it works perfectly, *EVERY TIME*... Its also
very very quick.
   So I tried again, create a new IAR project, include all the files, change
the output type to be intel extended and change the extension to .hex, load
the philips programmer, and blam, 1/3 of the way through, it dies.. Whats
more, a bit of ferreting around reveals it also locks up the USB->Serial
device. I've tried this with both debug and release versions of the output,
same result, I can't get code from IAR into the LPC2106!

  So, there's something wrong with the way that IAR embedded workbench is
generating the code. The output files are of a similar size (Iar = 5.7K and
the included one is 6.3k) so whats going on? Why should the IAR output file
be slower? Why should it crash it?

Paul Maddox

At 09:31 PM 10/15/04 +0100, you wrote:
>   So, I've done some more trying, used a different USB->Serial converter and
>the same problem.
>
>   Then I tried something else, the .hex file that comes with the S1(S2 or
>S3) example, and guess what, it works perfectly, *EVERY TIME*... Its also
>very very quick.
>    So I tried again, create a new IAR project, include all the files, change
>the output type to be intel extended and change the extension to .hex, load
>the philips programmer, and blam, 1/3 of the way through, it dies.. Whats
>more, a bit of ferreting around reveals it also locks up the USB->Serial
>device. I've tried this with both debug and release versions of the output,
>same result, I can't get code from IAR into the LPC2106!

That sounds quite bizarre. Have you loaded the resulting hex into an editor 
and verified that it is in fact a hex file?  IE no strange characters 
padded in somewhere.

The only other thing I can think of would be if the hex generated had some 
references to non-existant memory areas.  Hmm, Martin's LPC21ISP has a 
debug option to dump out a binary image of the hex, you might give that a 
try and see if there is something odd about the result.

Mind you, the USB->serial device shouldn't care what stream is sent to 
it.  Maybe it has an escape sequence it recognizes?

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

Robert,

> That sounds quite bizarre.

Yep, bizarre and very annoying.

> Have you loaded the resulting hex into an editor
> and verified that it is in fact a hex file?  IE no strange characters
> padded in somewhere.

I've loaded it into the LPC ISP Hex viewer thing, and it all looks fine to
me.. Though the code is very different.

> The only other thing I can think of would be if the hex generated had some
> references to non-existant memory areas.  Hmm, Martin's LPC21ISP has a
> debug option to dump out a binary image of the hex, you might give that a
> try and see if there is something odd about the result.

Do you have a link for this?

> Mind you, the USB->serial device shouldn't care what stream is sent to
> it.  Maybe it has an escape sequence it recognizes?

Possibly, though it would be a first, I've used this USB->Serial converter
for my AVR projects for months without a single problem.

Paul

At 12:15 AM 10/16/04 +0100, you wrote:
> > The only other thing I can think of would be if the hex generated had some
> > references to non-existant memory areas.  Hmm, Martin's LPC21ISP has a
> > debug option to dump out a binary image of the hex, you might give that a
> > try and see if there is something odd about the result.
>
>Do you have a link for this?

http://www.engelschall.com/~martin/lpc21xx/isp/index.html

The -debug switch will dump out a binary image I believe.  That's what I 
remember from viewing the source a little while ago.


> > Mind you, the USB->serial device shouldn't care what stream is sent to
> > it.  Maybe it has an escape sequence it recognizes?
>
>Possibly, though it would be a first, I've used this USB->Serial converter
>for my AVR projects for months without a single problem.

Strikes me as odd too but I can't imagine a serial stream halting the 
adapter otherwise.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

On Friday 15 October 2004 01:31 pm, Paul Maddox (Mail LIsts) wrote:
> Dear all,
>
>    So, I've done some more trying, used a different USB->Serial converter
> and the same problem.

I don't think the problem is with the USB to rs232.
>
>    Then I tried something else, the .hex file that comes with the S1(S2 or
>  S3) example, and guess what, it works perfectly, *EVERY TIME*... Its also
>  very very quick.

So the pre built hex files load just fine.

>     So I tried again, create a new IAR project, include all the files,
> change the output type to be intel extended and change the extension to
> .hex, load the philips programmer, and blam, 1/3 of the way through, it
> dies.. Whats more, a bit of ferreting around reveals it also locks up the
> USB->Serial device. I've tried this with both debug and release versions of
> the output, same result, I can't get code from IAR into the LPC2106!
>

Your hex files are bad.  check for the differences between the prebuilt and 
the ones you build.
http://www.cs.net/lucid/intel.htm has a nice page expaining the fields in the 
hex file. 
http://www.keil.com/support/docs/1584.htm is a good one too.

>    So, there's something wrong with the way that IAR embedded workbench is
>  generating the code. The output files are of a similar size (Iar = 5.7K
> and the included one is 6.3k) so whats going on? Why should the IAR output
> file be slower? Why should it crash it?

Bad address?   Checksum wrong?
>
>  Paul Maddox

Paul,
you should use default EWARM files included with S1 example.
Start EWARM, click->File->Open Workspace, select S1_test.eww.
Than click Project->Make.
I tested it !!! I also run through PC's USB and USB->RS232 converter.
Regards,
Yvon



--- In lpc2000@yahoogroups.com, "Paul Maddox (Mail LIsts)" 
<Paul.Maddox.Mail-list@S...> wrote:
> Dear all,
>  
>   So, I've done some more trying, used a different USB->Serial 
converter and
> the same problem.
> 
>   Then I tried something else, the .hex file that comes with the S1
(S2 or
> S3) example, and guess what, it works perfectly, *EVERY TIME*... 
Its also
> very very quick.
>    So I tried again, create a new IAR project, include all the 
files, change
> the output type to be intel extended and change the extension 
to .hex, load
> the philips programmer, and blam, 1/3 of the way through, it dies.. 
Whats
> more, a bit of ferreting around reveals it also locks up the USB-
>Serial
> device. I've tried this with both debug and release versions of the 
output,
> same result, I can't get code from IAR into the LPC2106!
> 
>   So, there's something wrong with the way that IAR embedded 
workbench is
> generating the code. The output files are of a similar size (Iar = 
5.7K and
> the included one is 6.3k) so whats going on? Why should the IAR 
output file

> be slower? Why should it crash it?
> 
> Paul Maddox

Yvon,

> you should use default EWARM files included with S1 example.
> Start EWARM, click->File->Open Workspace, select S1_test.eww.

I tried this, it says "Not a Project file"
Then "the project "c:\s1\s1_test.ewp" could not be opened, no real surprise,
as it doesn't exist, should there have been one?

Paul

Robert,

> http://www.engelschall.com/~martin/lpc21xx/isp/index.html
> 
> The -debug switch will dump out a binary image I believe.  That's what I
> remember from viewing the source a little while ago.

I'm not have much success,
This app doesn't work, it says "RecordType 04 not yet implimented" before it
even tries to program the device, and that¹s with the .hex file that¹s works
with the philips ISP.

Back to the drawing board
Paul

All,

So, after more investigation, I now think somehow the tinyARM won't accept
code.
I've tried it on another PC with a different OS, different serial adapter
and no matter what I try it says it lost communication with the device.
I can't even read the device ID now.

So, what can I do to get it back?

Paul

Just comment out the "exit" of record type 0x04 and try again.
This is planned for the next release !

Regards,

        Martin

----- Original Message ----- 
From: "Paul Maddox (Mail LIsts)" <Paul.Maddox.Mail-list@...>
To: <lpc2000@yahoogroups.com>
Sent: Saturday, October 16, 2004 6:18 PM
Subject: Re: [lpc2000] Problems Programming Part 2



Robert,

> http://www.engelschall.com/~martin/lpc21xx/isp/index.html
>
> The -debug switch will dump out a binary image I believe.  That's what I
> remember from viewing the source a little while ago.

I'm not have much success,
This app doesn't work, it says "RecordType 04 not yet implimented" before it
even tries to program the device, and that\ufffds with the .hex file that\ufffds works
with the philips ISP.

Back to the drawing board
Paul





Yahoo! Groups Links

--- In lpc2000@yahoogroups.com, "Paul Maddox (Mail LIsts)" 
<Paul.Maddox.Mail-list@S...> wrote:
> All,
> 
> So, after more investigation, I now think somehow the tinyARM won't 
accept
> code.
> I've tried it on another PC with a different OS, different serial 
adapter
> and no matter what I try it says it lost communication with the 
device.
> I can't even read the device ID now.
> 
> So, what can I do to get it back?
> 
> Paul

Hi Paul,
I have had a problem that seems simular to your though not exactly 
the same.  For a new prototytpe device we are designing we had 8 cpu 
boards manufactured, each with a LPC2114 microcontroller on board. 
Five of the eight boards programmed with no problem using IAR 
Workbench and a J-Link adapter.  The flash on three boards would not 
program no matter what I tried.  As a last resort, I had the LPC2114 
replaced on these three boards and the flash on all three of the new 
LPC2114s programmed with no problems.  Three out of eight bad 
LPC2114s seems very unlikely, but I have no other explanation for 
what I experienced.
Good Luck,
Bob Davis

I hate to admit this, but I had a similar problem with boards that did not work, turns out I had a 
floating voltage pin.  It looked great when I probed with the scope...  Oh well... I took the part 
off, cleaned the pads and resoldered...  Everything worked fine.

Tim Larson

  Hi Paul,
  I have had a problem that seems simular to your though not exactly 
  the same.  For a new prototytpe device we are designing we had 8 cpu 
  boards manufactured, each with a LPC2114 microcontroller on board. 
  Five of the eight boards programmed with no problem using IAR 
  Workbench and a J-Link adapter.  The flash on three boards would not 
  program no matter what I tried.  As a last resort, I had the LPC2114 
  replaced on these three boards and the flash on all three of the new 
  LPC2114s programmed with no problems.  Three out of eight bad 
  LPC2114s seems very unlikely, but I have no other explanation for 
  what I experienced.
  Good Luck,
  Bob Davis


[Non-text portions of this message have been removed]