I appologize for being clueless. Any help would be very appreciated.
This is my first experience with writing embedded software. I'm
using an ARM7 on the LPC2294 board. I have it plugged into a Phytec
HD200 test board. I used uV3 as an IDE for development.
So far I've successfully loaded and run the two example (blinky and
Hello) programs specifically written for the lpc22xx board. I've now
moved onto the CAN examples. The one I'm specifically trying to get
to work is CANBlinky. It compiles and I can put it on the board
without problems and it appears to be running (the LED is blinking)
but I'm getting nothing from CAN2 which is supposed to be
transmitting A/D data. Are there any gotchas when I try to run these
CAN examples on the 2294 board? The one thing I was mucking around
with was the target options. They were different than the ones in
the other two examples. I tried to make them match but some of the
options weren't available on the CANBlinky program.
Another thing I've noticed is in being able to debug. With the other
examples I was able to set breakpoints in the code and step through
things. This has been EXTREMELY helpful in helping me learn and
understand what's going on. But with the CANBlinky example, when I
try and debug, my breakpoints are never hit and when I stop the
debugger and try and step, All I ever get to see is the program
pointer in the disassembler going repeating the same 5 or six lines
of assembly over and over. I never get to step through the code.
Lastly, does anyone have any suggestions as to resources I can take
advantage of in learning the basics of programming for the ARM7? Any
books for beginners or the like? I'm a bit over my head with this
and it was dumped in my lap with a short timeframe to complete it.
Any help would be VERY appreciated.
Thanks.
Josh
CAN Examples on LPC2294
Started by ●June 15, 2005
Reply by ●June 15, 20052005-06-15
At 07:13 PM 6/15/05 +0000, Josh Ferguson wrote:
>So far I've successfully loaded and run the two example (blinky and
>Hello) programs specifically written for the lpc22xx board. I've now
>moved onto the CAN examples. The one I'm specifically trying to get
>to work is CANBlinky. It compiles and I can put it on the board
>without problems and it appears to be running (the LED is blinking)
>but I'm getting nothing from CAN2 which is supposed to be
>transmitting A/D data. Are there any gotchas when I try to run these
>CAN examples on the 2294 board?
First question. What else is hooked up to your CAN bus?
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/
>So far I've successfully loaded and run the two example (blinky and
>Hello) programs specifically written for the lpc22xx board. I've now
>moved onto the CAN examples. The one I'm specifically trying to get
>to work is CANBlinky. It compiles and I can put it on the board
>without problems and it appears to be running (the LED is blinking)
>but I'm getting nothing from CAN2 which is supposed to be
>transmitting A/D data. Are there any gotchas when I try to run these
>CAN examples on the 2294 board?
First question. What else is hooked up to your CAN bus?
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/
Reply by ●June 15, 20052005-06-15
--- In lpc2000@lpc2..., Robert Adsett <subscriptions@a...>
wrote:
> At 07:13 PM 6/15/05 +0000, Josh Ferguson wrote:
> >So far I've successfully loaded and run the two example (blinky and
> >Hello) programs specifically written for the lpc22xx board. I've
now
> >moved onto the CAN examples. The one I'm specifically trying to
get
> >to work is CANBlinky. It compiles and I can put it on the board
> >without problems and it appears to be running (the LED is blinking)
> >but I'm getting nothing from CAN2 which is supposed to be
> >transmitting A/D data. Are there any gotchas when I try to run
these
> >CAN examples on the 2294 board? > First question. What else is hooked up to your CAN bus?
>
> Robert
>
I have a PEAK CAN to USB connector connected to my laptop and I'm
running the software that came with that connector that simply
listens to the CAN and shows the packets or can send packets manually
back to the device.
wrote:
> At 07:13 PM 6/15/05 +0000, Josh Ferguson wrote:
> >So far I've successfully loaded and run the two example (blinky and
> >Hello) programs specifically written for the lpc22xx board. I've
now
> >moved onto the CAN examples. The one I'm specifically trying to
get
> >to work is CANBlinky. It compiles and I can put it on the board
> >without problems and it appears to be running (the LED is blinking)
> >but I'm getting nothing from CAN2 which is supposed to be
> >transmitting A/D data. Are there any gotchas when I try to run
these
> >CAN examples on the 2294 board? > First question. What else is hooked up to your CAN bus?
>
> Robert
>
I have a PEAK CAN to USB connector connected to my laptop and I'm
running the software that came with that connector that simply
listens to the CAN and shows the packets or can send packets manually
back to the device.
Reply by ●June 15, 20052005-06-15
At 09:13 PM 6/15/05 +0000, Josh Ferguson wrote:
>--- In lpc2000@lpc2..., Robert Adsett <subscriptions@a...>
>wrote:
> > At 07:13 PM 6/15/05 +0000, Josh Ferguson wrote:
> > >So far I've successfully loaded and run the two example (blinky and
> > >Hello) programs specifically written for the lpc22xx board. I've
>now
> > >moved onto the CAN examples. The one I'm specifically trying to
>get
> > >to work is CANBlinky. It compiles and I can put it on the board
> > >without problems and it appears to be running (the LED is blinking)
> > >but I'm getting nothing from CAN2 which is supposed to be
> > >transmitting A/D data. Are there any gotchas when I try to run
>these
> > >CAN examples on the 2294 board?
> >
> >
> > First question. What else is hooked up to your CAN bus?
> >
> > Robert
> >
>
>I have a PEAK CAN to USB connector connected to my laptop and I'm
>running the software that came with that connector that simply
>listens to the CAN and shows the packets or can send packets manually
>back to the device.
OK, I'm going to assume the example SW works. I don't know either the
board or the Peak convertor but I've a few more general things to check.
- 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.
- 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.
- 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.
- Another simple check make sure you haven't got your wires crossed.
- Also check to see if the Peak convertor has an isolated
interface. It may need power coming in from the bus side.
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/
>--- In lpc2000@lpc2..., Robert Adsett <subscriptions@a...>
>wrote:
> > At 07:13 PM 6/15/05 +0000, Josh Ferguson wrote:
> > >So far I've successfully loaded and run the two example (blinky and
> > >Hello) programs specifically written for the lpc22xx board. I've
>now
> > >moved onto the CAN examples. The one I'm specifically trying to
>get
> > >to work is CANBlinky. It compiles and I can put it on the board
> > >without problems and it appears to be running (the LED is blinking)
> > >but I'm getting nothing from CAN2 which is supposed to be
> > >transmitting A/D data. Are there any gotchas when I try to run
>these
> > >CAN examples on the 2294 board?
> >
> >
> > First question. What else is hooked up to your CAN bus?
> >
> > Robert
> >
>
>I have a PEAK CAN to USB connector connected to my laptop and I'm
>running the software that came with that connector that simply
>listens to the CAN and shows the packets or can send packets manually
>back to the device.
OK, I'm going to assume the example SW works. I don't know either the
board or the Peak convertor but I've a few more general things to check.
- 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.
- 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.
- 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.
- Another simple check make sure you haven't got your wires crossed.
- Also check to see if the Peak convertor has an isolated
interface. It may need power coming in from the bus side.
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/
Reply by ●June 15, 20052005-06-15
Yahoo Groups just went screwy on me so I lost my nice long response.
I'll do what I can to repeat it.
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.
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.
> - 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.
> - 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.
> - 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.
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? 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? If anybody has an idea, I'd really like to
hear some suggestions.
Thanks.
Josh
I'll do what I can to repeat it.
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.
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.
> - 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.
> - 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.
> - 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.
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? 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? If anybody has an idea, I'd really like to
hear some suggestions.
Thanks.
Josh
Reply by ●June 16, 20052005-06-16
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/
>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/
Reply by ●June 16, 20052005-06-16
--- In lpc2000@lpc2..., Robert Adsett <subscriptions@a...>
wrote:
> 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.
Try hook your board up with the existing network.
>
>
> >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.
CAN is pretty reslient to improper termination , but on short
networks with cleanish conditions it isn't very fussy. A "lumped"
termination of 1 x 60R should be fine. >
> 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...
You aren't twisting CAN-hi to CAN lo are you?
You must connect all the CANHIs together and all the CANLOs together.
>
> 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.
One thing to do is to disconnect everything, just putting a
termination resistor across the sending node. Now watch the signal
with a scope....
The CAN controllers send out their message and wait for an ACK. If no
ACK is received they automatically re-transmit.
This is a neat way of checking that your node is really transmitting
and that gives you a way to check the bitrate is corect etc.
wrote:
> 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.
Try hook your board up with the existing network.
>
>
> >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.
CAN is pretty reslient to improper termination , but on short
networks with cleanish conditions it isn't very fussy. A "lumped"
termination of 1 x 60R should be fine. >
> 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...
You aren't twisting CAN-hi to CAN lo are you?
You must connect all the CANHIs together and all the CANLOs together.
>
> 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.
One thing to do is to disconnect everything, just putting a
termination resistor across the sending node. Now watch the signal
with a scope....
The CAN controllers send out their message and wait for an ACK. If no
ACK is received they automatically re-transmit.
This is a neat way of checking that your node is really transmitting
and that gives you a way to check the bitrate is corect etc.
Reply by ●June 16, 20052005-06-16
Hello Josh,
have you adapted your example "CanBlinky" from the MCB2100 Board to
the Phytec Board? The Baudrate settings for canbtr-register are right?
(see message 6065 from dietmar).
Try the other Canexamples in the FileSection. They worked fine for me
and I use the same environment (PhytecLpc2294 on HD200 with KeilIde).
You can find a good book for beginners at hitex.co.uk/arm from Trevor
Martin.
Klaus --- In lpc2000@lpc2..., "Josh Ferguson" <joshandrebekah@y...>
wrote:
> I appologize for being clueless. Any help would be very appreciated.
>
> This is my first experience with writing embedded software. I'm
> using an ARM7 on the LPC2294 board. I have it plugged into a Phytec
> HD200 test board. I used uV3 as an IDE for development.
>
> So far I've successfully loaded and run the two example (blinky and
> Hello) programs specifically written for the lpc22xx board. I've now
> moved onto the CAN examples. The one I'm specifically trying to get
> to work is CANBlinky. It compiles and I can put it on the board
> without problems and it appears to be running (the LED is blinking)
> but I'm getting nothing from CAN2 which is supposed to be
> transmitting A/D data. Are there any gotchas when I try to run these
> CAN examples on the 2294 board? The one thing I was mucking around
> with was the target options. They were different than the ones in
> the other two examples. I tried to make them match but some of the
> options weren't available on the CANBlinky program.
>
> Another thing I've noticed is in being able to debug. With the other
> examples I was able to set breakpoints in the code and step through
> things. This has been EXTREMELY helpful in helping me learn and
> understand what's going on. But with the CANBlinky example, when I
> try and debug, my breakpoints are never hit and when I stop the
> debugger and try and step, All I ever get to see is the program
> pointer in the disassembler going repeating the same 5 or six lines
> of assembly over and over. I never get to step through the code.
>
> Lastly, does anyone have any suggestions as to resources I can take
> advantage of in learning the basics of programming for the ARM7? Any
> books for beginners or the like? I'm a bit over my head with this
> and it was dumped in my lap with a short timeframe to complete it.
>
> Any help would be VERY appreciated.
>
> Thanks.
>
> Josh
have you adapted your example "CanBlinky" from the MCB2100 Board to
the Phytec Board? The Baudrate settings for canbtr-register are right?
(see message 6065 from dietmar).
Try the other Canexamples in the FileSection. They worked fine for me
and I use the same environment (PhytecLpc2294 on HD200 with KeilIde).
You can find a good book for beginners at hitex.co.uk/arm from Trevor
Martin.
Klaus --- In lpc2000@lpc2..., "Josh Ferguson" <joshandrebekah@y...>
wrote:
> I appologize for being clueless. Any help would be very appreciated.
>
> This is my first experience with writing embedded software. I'm
> using an ARM7 on the LPC2294 board. I have it plugged into a Phytec
> HD200 test board. I used uV3 as an IDE for development.
>
> So far I've successfully loaded and run the two example (blinky and
> Hello) programs specifically written for the lpc22xx board. I've now
> moved onto the CAN examples. The one I'm specifically trying to get
> to work is CANBlinky. It compiles and I can put it on the board
> without problems and it appears to be running (the LED is blinking)
> but I'm getting nothing from CAN2 which is supposed to be
> transmitting A/D data. Are there any gotchas when I try to run these
> CAN examples on the 2294 board? The one thing I was mucking around
> with was the target options. They were different than the ones in
> the other two examples. I tried to make them match but some of the
> options weren't available on the CANBlinky program.
>
> Another thing I've noticed is in being able to debug. With the other
> examples I was able to set breakpoints in the code and step through
> things. This has been EXTREMELY helpful in helping me learn and
> understand what's going on. But with the CANBlinky example, when I
> try and debug, my breakpoints are never hit and when I stop the
> debugger and try and step, All I ever get to see is the program
> pointer in the disassembler going repeating the same 5 or six lines
> of assembly over and over. I never get to step through the code.
>
> Lastly, does anyone have any suggestions as to resources I can take
> advantage of in learning the basics of programming for the ARM7? Any
> books for beginners or the like? I'm a bit over my head with this
> and it was dumped in my lap with a short timeframe to complete it.
>
> Any help would be VERY appreciated.
>
> Thanks.
>
> Josh
