At 10:41 PM 6/15/05 +0000, Josh Ferguson wrote:
>I'm relatively sure that the CAN to USB connector and the software
>are running fine. I borrowed a test board from a co-worker that's
>working on something similar but with the 8051 board and his CAN is
>working. I hooked it up to my laptop and the software registered
>getting packets.
Good to have confirmation of that.
>I'll try and answer your other points now.
>
> >
> > - termination. Both ends of your cable need to be
> > terminated. BTW what are you using for cable? It is possible even
>likely
> > that neither the board or the Peak convertor have on-board
>termination
> > since the usual use of CAN is on a bus and only the ends of the bus
>should
> > be terminated.
>
>Like I said above, I think this is a non issue because it worked with
>another chip and board. The only difference was that I had to use a
>gender changer on mine to plug the PEAK CAN to USB converter into my
>board.
That shows it might be terminated. Unfortunately since CAN is relatively
resilient it doesn't prove it. If the board and the converter have
terminators on them they MUST have a way to disable them, otherwise they
would never work on an existing bus. If they don't have a way to disable
termination they very likely don't have termination and it must be provided.
You mention using a gender changer. You are not plugging the Peak
converter directly into the LPC2294 board are you? That could cause
problems. As I recall there is a minimum distance between nodes as well as
a maximum bus length. It ends up being a function of transmitter and
receiver delays as well as the signal speed on the bus. It's not usually a
problem but...
These sort of problems, bus length, missing termination etc... are exactly
the sort of problems that will work in some combinations and conditions and
fail in others in a CAN based network. In some cases you get "lucky" and
the built-in retry mechanisms get the message through often enough for you
not to notice the problem, especially if you are bringing up your first
network.
> > - baud rate. Make sure both sides are using the same baud
> > rate. Unfortunately that's not as straight forward a question as
>it sounds
> > since the rate is determined by the interaction of a set of
>parameters.
>
>This I'll have to do more searching on. I did check every one of the
>preset baud rates in the software on the laptop and none of them
>worked, but I'll do some more looking and get back to you.
>
> > - I expect that the Peak SW will include a facility to
>show the
> > error counters and bus state. It would be a good idea to take a
>look at
> > them although I expect at this point all they will tell you is that
>you are
> > in buss off state due to accumulated errors. Speaking of which,
>you must
> > reset both ends when retrying, otherwise you will be stuck in bus-
>off and
> > won't end up testing the changes.
>
>The only information I have about the buss in the software is that I
>get a "BUSHEAVY" message (whatever that is) when I unplug and plug in
>the cable to the board. It also tells me that overruns are 0 and
>QXmtFull (whatever that is) is 0.
Hmm, I would have expected they'd report all the errors states they
could. Maybe they've buried it somewhere. Then again, maybe my
expectations are too high :)
> > - Another simple check make sure you haven't got your
>wires crossed.
>
>Since it worked on the other board, I have to assume this is ok.
If they are using standard CiA Dsub pinout that seems a good
possibility. I'd still verify it though. Basic rule of thumb I have when
simple communications fail. First check your own wiring then verify that
the manufacturer didn't mess it up either ;)
> > - Also check to see if the Peak convertor has an isolated
> > interface. It may need power coming in from the bus side.
> >
>
>The PEAK converter gets its power from the USB cable according to the
>website.
The fact that it works with the other board makes this likely as well,
provided you are only running three wires between the board and the Peak
converter. The boards I used for this came default as isolated and
expected 12-24V in on the DSub to power the bus side of the optos. In fact
I think the CiA spec nearly requires this but I didn't spend much time with
it, I was working to other specs. I had 5V available and had to modify the
cards to jumper around the internal 5V regulator.
And of course you want to make the same check on your LPC board.
>I appreciate your help on this, Robert. Some questions I have
>thought of, though I'm not experienced enough to know the answers to
>are: Is there a change in the code that is needed to make code
>targeted for a lpc2100 work on a lpc22xx board?
Peripherals, flash programming, maybe top of ram. I'd expect most of the
differences to be in memory organization. If you were comparing specific
peripherals I'd read through the user manual for both to make sure they
were the same though. Also I'd check the errata.
>What changes to the
>target options (if any) would I have to make? Are the clock speeds
>different for the different boards meaning I would have to
>recalculate my baud rate?
AFAIK all the LPCs use the same basic clock circuitry. Anyone know 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
http://www.aeolusdevelopment.com/