Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Thread

ISP

ISP

2004-05-28 by mjbcswitzerland

Hi all

Here's the story. I have an IAR Philips LPC210x Kickstart card and 
all works well - i.e. J-Link JTAG and ISP programming.

Now I have just received my own board and JTAG works fine. Found a 
big mistake since I didn't realise that I loose 10 ports due to JTAG 
1 (ETM is also activated). This means that the board is useless in 
JTAG 1 mode for the moment so decided to use a FLASH monitor program 
over port 0 until a solution is found (redesign for JTAG 2 perhaps).

No problem synchronising and reading the ID stuff. The download 
starts and gets to 10% and sometimes up to 30% before aborting with 
a communication error.

Have tried baud rates down to 1200 with no success (always same 
behaviour). Have 12MHz quarz but removed it and drove the input from 
the 14.7..MHz from kickstart board (through 100pF) - same behaviour.

Checked the data on RS-232 interface - typically a Mxxxxxxx command 
is being sent and the 
characters are being echoed back. Suddenly the echo stops in the 
middle of a message and thats it - no more response until the card 
is reset.

Have checked some YAHOO-discussions but doen't see any real info - 
are things like crystal caps, bypass caps, driver decoupling really 
the cause of such problems? Seems a bit sensitive....

By the way: Using JTAG1 I have a program using serial ports 0 and 1 
at 19'200 on my target (the one with the ISP problem) with 
absolutely no problems so why can the ISP download go wrong? It 
doesn't seem as though it's a flash programming problem because it 
probably doesn't get this far (or does it??)

Any tips to get me back on the track???

Would be very grateful for any help.

Regards

Mark Butcher

Switzerland

Re: ISP

2004-05-28 by mjbcswitzerland

I would like to add some more information concerning the problem I 
am having. (ISP FLASH upload).

Some thing measured:
- 1.8V is accurate and stable (no glitches) when the ISP fails
- 3.3V is accurate and stable (no glitches) when the ISP fails
- reset line stable '1' when the ISP fails.

I have connected the Rx input (3.3V level from the Kickstart board 
to the Rx input (directly at processor) on my board. The upload 
still fails (it works on the Kickstart board, which is sending echos 
and operating in parallel) but the Tx stops sometime during the 
upload on mine [Tx obviously not connected to ISP utility - only for 
monitoring]).

It seems as though the Read Device ID is very reliable. It works 
hundreds of times in a row and a blank check and erase (although 
always blank) don't cause a 'crash'. So it is likely that it is 
during Flash programming itself.

One difference from the Kickstart board is that I am using a mix of 
3.3V and 5V, which means that some inputs are at 5V level (also the 
Tx line is pulled up to 5V by the RS-232 driver chip input when in a 
high impedance state - eg. just before ISP synchronisation).

Since the communication itself seems reliable (presently using 
19'200) it would seem to be a power supply issue, although all is 
very stable. Are then any ports which don't like 5V for example?

I'm beginning to get nervous.

Cheers

Mark Butcher


--- In lpc2000@yahoogroups.com, "mjbcswitzerland" 
<mjbcswitzerland@y...> wrote:
> Hi all
> 
> Here's the story. I have an IAR Philips LPC210x Kickstart card and 
> all works well - i.e. J-Link JTAG and ISP programming.
> 
> Now I have just received my own board and JTAG works fine. Found a 
> big mistake since I didn't realise that I loose 10 ports due to 
JTAG 
> 1 (ETM is also activated). This means that the board is useless in 
> JTAG 1 mode for the moment so decided to use a FLASH monitor 
program 
> over port 0 until a solution is found (redesign for JTAG 2 
perhaps).
> 
> No problem synchronising and reading the ID stuff. The download 
> starts and gets to 10% and sometimes up to 30% before aborting 
with 
> a communication error.
> 
> Have tried baud rates down to 1200 with no success (always same 
> behaviour). Have 12MHz quarz but removed it and drove the input 
from 
> the 14.7..MHz from kickstart board (through 100pF) - same 
behaviour.
> 
> Checked the data on RS-232 interface - typically a Mxxxxxxx 
command 
> is being sent and the 
> characters are being echoed back. Suddenly the echo stops in the 
> middle of a message and thats it - no more response until the card 
> is reset.
> 
> Have checked some YAHOO-discussions but doen't see any real info - 
> are things like crystal caps, bypass caps, driver decoupling 
really 
> the cause of such problems? Seems a bit sensitive....
> 
> By the way: Using JTAG1 I have a program using serial ports 0 and 
1 
Show quoted textHide quoted text
> at 19'200 on my target (the one with the ISP problem) with 
> absolutely no problems so why can the ISP download go wrong? It 
> doesn't seem as though it's a flash programming problem because it 
> probably doesn't get this far (or does it??)
> 
> Any tips to get me back on the track???
> 
> Would be very grateful for any help.
> 
> Regards
> 
> Mark Butcher
> 
> Switzerland

RE: [lpc2000] Re: ISP

2004-05-29 by James Dabbs

>It seems as though the Read Device ID is very reliable. It works 
>hundreds of times in a row and a blank check and erase (although 
>always blank) don't cause a 'crash'. So it is likely that it is 
>during Flash programming itself.

I had this same problem.  It turned that I had insufficient bypassing on
the RS-232 converter chip.  It worked fine to read the ID, which let me
to believe the communications were reliable.  But with longer
transactions (i.e., programming FLASH), it failed because of bit errors.

Beyond this, I never could get JTAG2 to work reliably.  I wound up
bringing up my code on a Nohau eval board, getting the serial port
working enough to serve as a debug/console port, and then bringing it up
the rest of the way on the target board.  This experience was right up
there in terms of embedded development hell.  If you get JTAG2 to work,
please let me know how as I am steering clear of it going forward.

Regards,

James Dabbs, TGA

Re: [lpc2000] Re: ISP

2004-05-29 by Robert Adsett

Definitely check out James comments.  I've a few questions/comments myself.

At 10:50 PM 5/28/04 +0000, you wrote:
>I have connected the Rx input (3.3V level from the Kickstart board
>to the Rx input (directly at processor) on my board. The upload
>still fails (it works on the Kickstart board, which is sending echos
>and operating in parallel) but the Tx stops sometime during the
>upload on mine [Tx obviously not connected to ISP utility - only for
>monitoring]).

I've re-read this several times thinking I've read it wrong.  Let me see if 
I've got this right.

- You have TX from the PC hooked up to RX on the kickstart board and RX on 
your board.
- You have RX on the PC hooked up to TX on the kickstart board.

Is this the only way you have tested it?

If you haven't run your board alone, I suggest you do so because the 
symptoms you are reporting are exactly what I would expect from this 
hookup.  As long as the micros don't have to do anything (or the kickstart 
is slower than yours) they will stay in sync.  As soon as  your micro takes 
longer than the kickstart to perform an operation it will receive a command 
before it is ready for it and .....

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

Re: ISP

2004-05-29 by sig5534

> Beyond this, I never could get JTAG2 to work reliably.  

That sure caught my attention.  I am laying out a design right now 
and noticed that ETM was always enabled with the JTAG primary port.  
Therefore I planned on using the secondary JTAG port so as not to 
kill off the ETM pins.

Now you say that the secondary JTAG port does not work?
Has anybody else had this experience?

Regards,  Chris.

Re: ISP

2004-05-29 by ian48harry

Guys:

Both JTAG ports work fine.  Philips would be shot if they did not.  
Other eval boards have both JTAGs and ETM working fine.  Simple board 
designs don't always think what needs to be done on these multi-
function pins.

Ian

--- In lpc2000@yahoogroups.com, "sig5534" <sig5534@h...> wrote:
> > Beyond this, I never could get JTAG2 to work reliably.  
> 
> That sure caught my attention.  I am laying out a design right now 
> and noticed that ETM was always enabled with the JTAG primary 
port.  
Show quoted textHide quoted text
> Therefore I planned on using the secondary JTAG port so as not to 
> kill off the ETM pins.
> 
> Now you say that the secondary JTAG port does not work?
> Has anybody else had this experience?
> 
> Regards,  Chris.

Re: ISP

2004-05-29 by sig5534

> Both JTAG ports work fine.  Philips would be shot if they did not.  
> Other eval boards have both JTAGs and ETM working fine.  

That's what I would have thought.  I read the Appnote from Ashling 
about setting up the JTAG #2 port and it must be done correctly.  
There are quite a few details and must pay careful attention to.

Thanks,  Chris.

Re: ISP (explaination of difficult sentence)

2004-05-29 by mjbcswitzerland

Hi Robert

It's a difficult sentence, I admit. What I wanted to say is that I 
used the Rx transceiver on the Kickstart Board (instead of the 
MAX202 on my board) to ensure that the Rx signal at the LPC2106 is 
really clean (I have read a lot about bad decoupling etc. at the 
transceivers leading to unreliability).

Of course I was testing previously directly with my board which uses 
a 5V MAX202 transceiver and with this test I wanted to see whether 
there was a difference using a 3V transceiver and also a known good 
RX path.

In fact the ISP utility is communicating with the Kickstart board 
and my board is simply listening in to the data received by the 
kickstart board. It responds and I compared its responses with those 
from the Kicksrat board. During an upload to the kick start board my 
board receives the same info and responds - the upload is successful 
since the responses seen at the ISP utility are from the Kickstart 
board which works perfectly. I monitor the responses from my board, 
which abruptly stop somewhere during the process.

This means that I am definitely sure that it's not a tranceiver 
problem.

In the mean time there is a little more information available:
- a second board shows identical symptoms and so it is a systematish 
problem with the hardware on my board.
- a friend of mine is also using the same chip in a different design 
(the chips he has are from the same batch as the ones on my boards, 
since we are working together on two pieces of equipment which 
communicate with each other). He confirms the problem with my board 
using his tools but has absolutely no difficulties with his 
hardware. We are using the same MAX202 circuitry (at 5V)..
- I am presently comparing in detail the differences between my 
hardware and his hardware - we both designed the two circuits in 
parallel and so obviously they are pretty much the same apart from 
the use of the ports. He uses only a few - all at 3.3V - but my 
design all of them, several at 5V level. Also the power suppy chips 
are identical with 2 x LM1117-ADJ for 3.3V and 1.8V and exactly the 
same voltage setting resistors.

This means that I will be spending my Saturday night stripping down 
my circuitry to an equivalent state as the other until it suddenly 
starts to work (I hope) - it should be a matter of time.

By the way, we both missed the fact that we loose 10 ports when 
using JTAG1 and both have the same problem with our hardware - they 
need redesigns if we want to use JTAG2 to get them back. Since we 
know JTAG well we didn't spend too much time considering the 
interface in great detail. JTAG1 worked well on the demo board and 
the ETM interface isn't of interest - the ETM mode of the ports is 
described as an alternative use in the Port section so that seemed 
to be flexible enough. In fact it takes quite detailed reading of 
the user manual to identify the fact that JTAG1 activation steals 10 
ports from you whether you like it or not. It would be a good idea 
for Philips to modify the document with a large warning - it would 
have saved us a lot of time and the boards reworks are not exacly 
cheap.

Hope to post a reason and cure soon.

Cheers

Mark Butcher


--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> 
wrote:
> Definitely check out James comments.  I've a few 
questions/comments myself.
> 
> At 10:50 PM 5/28/04 +0000, you wrote:
> >I have connected the Rx input (3.3V level from the Kickstart board
> >to the Rx input (directly at processor) on my board. The upload
> >still fails (it works on the Kickstart board, which is sending 
echos
> >and operating in parallel) but the Tx stops sometime during the
> >upload on mine [Tx obviously not connected to ISP utility - only 
for
> >monitoring]).
> 
> I've re-read this several times thinking I've read it wrong.  Let 
me see if 
> I've got this right.
> 
> - You have TX from the PC hooked up to RX on the kickstart board 
and RX on 
> your board.
> - You have RX on the PC hooked up to TX on the kickstart board.
> 
> Is this the only way you have tested it?
> 
> If you haven't run your board alone, I suggest you do so because 
the 
> symptoms you are reporting are exactly what I would expect from 
this 
> hookup.  As long as the micros don't have to do anything (or the 
kickstart 
> is slower than yours) they will stay in sync.  As soon as  your 
micro takes 
> longer than the kickstart to perform an operation it will receive 
a command 
> before it is ready for it and .....
> 
> 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
Show quoted textHide quoted text
> chew a radio signal. "
> 
>                          Kelvin Throop, III

Keil and Printf

2004-05-29 by Rob R

Hi,

 

Anyone know how to use the printf function which is provided with Keil?

I can't seem to get the compiler to stop moaning about not finding the
function definition, even when I include stdio.h and printf.h.


Which UART does it redirect to?

Many thanks

 

Rob

Re: [lpc2000] Re: ISP (explaination of difficult sentence)

2004-05-29 by Robert Adsett

At 07:44 PM 5/29/04 +0000, you wrote:
>It's a difficult sentence, I admit. What I wanted to say is that I
>used the Rx transceiver on the Kickstart Board (instead of the
>MAX202 on my board) to ensure that the Rx signal at the LPC2106 is
>really clean (I have read a lot about bad decoupling etc. at the
>transceivers leading to unreliability).

Or it may just mean I was up too late :)

>Of course I was testing previously directly with my board which uses
>a 5V MAX202 transceiver and with this test I wanted to see whether
>there was a difference using a 3V transceiver and also a known good
>RX path.
>
>In fact the ISP utility is communicating with the Kickstart board
>and my board is simply listening in to the data received by the
>kickstart board. It responds and I compared its responses with those
>from the Kicksrat board. During an upload to the kick start board my
>board receives the same info and responds - the upload is successful
>since the responses seen at the ISP utility are from the Kickstart
>board which works perfectly. I monitor the responses from my board,
>which abruptly stop somewhere during the process.
>
>This means that I am definitely sure that it's not a tranceiver
>problem.

I don't share your certainty here.  Let me sketch out a case where your 
setup could fail even when all the components work.  Each line represents a 
moment in time.  If you line up the '|'s you should see a table of events 
in time during programming.  This is just a rough sketch and I've certainly 
left out details but it captures what I'd be worried about.


     PC                                     | 
Kickstart                                 | Your 
Board                          | Monitor
     ...                                       | 
                   |                                            |
1   Send Write data to 
ram       |                                              | 
                           |
2                                            | Receives 
Data                        | Receives Data                      |
3                                  | Returns CMD_SUCCESS       |  Returns 
CMD_SUCCESS     |
4  Receives 
CMD_SUCCESS   |                                              | 
                               |   Receives CMD_SUCCESS
5  Send Copy RAM to 
Flash      |                                              | 
                            |
6                                            | Starts copy  RAM to 
Flash       | Starts copy  RAM to Flash      |
7                                             | 
                  | Finishes copy  RAM to Flash  |
8                                            | Finishes copy  RAM to 
Flash     | Sends CMD_SUCCESS       |
9                                             | Sends 
CMD_SUCCESS           |                                           | 
Receives Sends CMD_SUCCESS
10 Receives 
CMD_SUCCESS   |                                               | 
                                |
11  Send Write data to 
ram       |                                              | 
                           |
..... Repeat multiple times
12  Send Write data to 
ram       |                                              | 
                           |
13                                           | Receives 
Data                        | Receives Data                      |
14                                     | Returns 
CMD_SUCCESS       |  Returns CMD_SUCCESS     |
15 Receives 
CMD_SUCCESS   |                                              | 
                               |   Receives CMD_SUCCESS
16 Send Copy RAM to 
Flash      |                                              | 
                            |
17                                           | Starts copy  RAM to 
Flash       | Starts copy  RAM to Flash      | Starts copy  RAM to Flash
18                                            | Finishes copy  RAM to 
Flash   |                                            |
19                                            | Sends 
CMD_SUCCESS           |                                           |
20 Receives 
CMD_SUCCESS   |                                               | 
                                |
21   Send Write data to 
ram       |                                              | 
                           |
22                                            | Receives 
Data                        | EEEK!!                                |

At line 22 (where I've put EEEK!!) your board receives a command it's 
simply not ready for.  It's not clear what will happen at this point but I 
doubt that it's good.   In fact I suspect it will leave the micro very 
confused and it's possible it will abort the program cycle it is in.  It 
may at that point be so confused that it is effectively dead until it's 
reset, there appears to be no documentation that hints at any sort of 
recovery or error detecting strategy. I also suspect that the probability 
of this happening approaches unity as you program more and more lines.


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

Re: Keil and Printf

2004-05-30 by leon_heller

--- In lpc2000@yahoogroups.com, "Rob R" <rob@r...> wrote:
>  Hi,
> 
>  
> 
> Anyone know how to use the printf function which is provided with 
Keil?
> 
> I can't seem to get the compiler to stop moaning about not finding 
the
> function definition, even when I include stdio.h and printf.h.
> 
> 
> Which UART does it redirect to?

Perhaps it just works with the debugger. This is the case with some 
other development software I've used, like ADI's VisualDSP.

Leon

RE: [lpc2000] Re: ISP

2004-05-30 by James Dabbs

> Both JTAG ports work fine.  Philips would be shot if they did not.  

I am sure that this is true.  But it is very fragile for a debug
mechanism.  From my experience and from earlier postings on this group,
a developer might assume that using the secondary JTAG port on their
first LPC210X project will likely add to their timeline.

ISP Upload problem solved

2004-05-31 by mjbcswitzerland

Hi all

I have at last solved the ISP upload problem.

It turned out to be due to a chip in the RX path. For my application 
the ISP capability is a security issue and the rx path is monitored 
by a second device which will destroy information if it detectes an 
ISP download. To ensure that this will always work, even when the 
voltages to the two different devices are different, the Rx signal 
is buffered with a schmitt-trigger - it is this buffer which is 
rather fast and has some fast overshoot/ringing. Obviously the 
LPC2106 doesn't like this at all and uploads always failed.

After dampening the ringing it works.

So anyone with a similar issue - check the RX signal quality. It 
should be a nice square wave signal without ringing or overshoot - 
then it just works - like magic.

Cheers

Mark Butcher

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.