All,
I'm looking for people who have experience with programming the flash
on the new AT91SAM7X512 chips. Specifically, programming it using the
two internal flash controllers (AT91C_MC_FCR0 and 1).
I believe we are seeing a problem where using the chip to self-program
results in damage to the chip that ultimately prevents any further
flashing of flash plane 0.
This is not happening to all of our 512's, but it's enough of them
to
make us gravely concerned about it.
We have been using both the AT91SAM7X256 and 512 parts since the early
days of the 512's availability (from engineering samples through
production parts with date codes 0817, 0824, and now 0831). We have
many, MANY of these parts which flash and run perfectly and I am able
to re-load the flash via self-programming, or downloading a flash
program via the JTAG. It's just that some of these parts seem to
"self destruct" on us when we try to program them with the internal
flash controller.
In a nutshell, our experience goes like this:
1) Start with a code image exactly 256KB so it fits inside the first
flash plane and does not extend into the 2nd. (This image would work
equally well on a AT91SAM7X256.)
1) Program a bare 512 part on a Data IO gang programmer. Everything
verifies, GPNVM bit 2 is set, etc.
2) Solder the part onto a board.
3) Load board into our instrument, verify that our code executes and
everything runs fine.
4) Begin the code update process which does a download of the new
program into the 512 part. We store the image in a separate
non-volatile storage temporarily, load the code loading process into
RAM, execute out of RAM during the loading process, and copy blocks
from the non-volatile into the flash. This process has worked
hundreds and hundreds of times successfully during development on our
product.
5) The part fails when it reboots. Multiple 256 bytes pages are
corrupted. Checksums are invalid, if even the checksumming code gets
to run, which many times it does not.
6) Attach a JTAG probe and run another flashing utility on the part,
which resides in RAM. The program does a full ERASE of the part, then
tries to write a simple 256 bytes of 0's into both flash plane 0 and 1.
7) Observe that the first plane of flash (0x100000 to 0x13FFFF) is
either horribly corrupted or takes none of the 0's at all. Also then
observe that the second plane of flash (0x140000 to 0x180000) works
normally and takes the writes as you might expect.
8) The part is now "dead" and cannot ever be written to again, for
plane 0.
It should be noted that we are not violating the rule that says you
cannot be running code in flash while altering flash. Our flashing
code runs from RAM and actually ERASES the entire flash before writing
the new image to it.
This is a VERY puzzling problem. It does not affect all parts, and it
does not seem to happen the first time my gang programmer writes the
part. It only seems to happen when I run my self flashing code.
If you are working with this part, I ask that you please contact me
either via this post or privately to p...@gmail.com where we can
compare notes.
I do not write this to create a big stink for Atmel, but merely to get
to the bottom of this issue. We are desperate to make this part work
in our product (a medical device).
We have also begun contact with Atmel regarding this issue but I have
to wonder, who else is using the flash controller in this way, and are
they having the problem as well? How could we be the only ones seeing
this?
Thanks!
Paul
p...@gmail.com
AT91SAM7X512 flash damage during programming
Started by ●August 27, 2008
Reply by ●August 28, 20082008-08-28
Hi
I'm looking at doing a project for some robotics work and want to
provide autonomous operations but also with a RC override in case of
issue's but also to allow for switching of RC to and from Autonomous
operations
Here's the setup
I'm looking at a AT91SAM7X or a Xilinx CLPD to do this
in is most basic form what I want to do is have it take as inputs
up to 16 Channel's from a RC Receiver (direct from Servo outs) 1-2ms pulse
and a SCS-32 Channel Servo Controller from Lynxmotion.
the output would be 32 Channels with the first 16 Channels normally
controlled by the SCS-32 (remaining 16 always controlled by the SCS-32)
but by a flip of a switch on the RC remote (Gear switch for example) the
controller will override the first 16 channels and begin sending the RC
signals instead. flip the switch again and the SCS-32 is back in control.
But also, I want it to read the 16 channels from the RC receiver and
report position info on each channel via Serial interface (SPI/I2C or
RS232)
It also will need to do the switch in a safe manner. i.e. just switch
may cause a motion more dangerous than what was happening in the first place
so it needs to watch those first 16 channels on the SCS-32 and correctly
and smoothly switch control to the remote.
No the question
I know I can do this with the AT91SAM7X, it has the IO I need.
a CLPD may be a better choice but I'm not as familure with them. I do
have a Dev Kit to play with though
Considering the setup, that data transfers are occurring etc..
Which is in your opinions the best way to go? SAM7X or Xilinx?
I will say based on my limited knowledge the SAM7X would appear to be
better but I value your opinions
Thank you
William Carroll
I'm looking at doing a project for some robotics work and want to
provide autonomous operations but also with a RC override in case of
issue's but also to allow for switching of RC to and from Autonomous
operations
Here's the setup
I'm looking at a AT91SAM7X or a Xilinx CLPD to do this
in is most basic form what I want to do is have it take as inputs
up to 16 Channel's from a RC Receiver (direct from Servo outs) 1-2ms pulse
and a SCS-32 Channel Servo Controller from Lynxmotion.
the output would be 32 Channels with the first 16 Channels normally
controlled by the SCS-32 (remaining 16 always controlled by the SCS-32)
but by a flip of a switch on the RC remote (Gear switch for example) the
controller will override the first 16 channels and begin sending the RC
signals instead. flip the switch again and the SCS-32 is back in control.
But also, I want it to read the 16 channels from the RC receiver and
report position info on each channel via Serial interface (SPI/I2C or
RS232)
It also will need to do the switch in a safe manner. i.e. just switch
may cause a motion more dangerous than what was happening in the first place
so it needs to watch those first 16 channels on the SCS-32 and correctly
and smoothly switch control to the remote.
No the question
I know I can do this with the AT91SAM7X, it has the IO I need.
a CLPD may be a better choice but I'm not as familure with them. I do
have a Dev Kit to play with though
Considering the setup, that data transfers are occurring etc..
Which is in your opinions the best way to go? SAM7X or Xilinx?
I will say based on my limited knowledge the SAM7X would appear to be
better but I value your opinions
Thank you
William Carroll
Reply by ●August 28, 20082008-08-28
On Friday 29 August 2008 07:28:03 William Carroll wrote:
> Hi
>
> I'm looking at doing a project for some robotics work and want to
> provide autonomous operations but also with a RC override in case of
> issue's but also to allow for switching of RC to and from Autonomous
> operations
>
> Here's the setup
> I'm looking at a AT91SAM7X or a Xilinx CLPD to do this
> in is most basic form what I want to do is have it take as inputs
> up to 16 Channel's from a RC Receiver (direct from Servo outs) 1-2ms pulse
> and a SCS-32 Channel Servo Controller from Lynxmotion.
> the output would be 32 Channels with the first 16 Channels normally
> controlled by the SCS-32 (remaining 16 always controlled by the SCS-32)
> but by a flip of a switch on the RC remote (Gear switch for example) the
> controller will override the first 16 channels and begin sending the RC
> signals instead. flip the switch again and the SCS-32 is back in control.
>
> But also, I want it to read the 16 channels from the RC receiver and
> report position info on each channel via Serial interface (SPI/I2C or
> RS232)
> It also will need to do the switch in a safe manner. i.e. just switch
> may cause a motion more dangerous than what was happening in the first
> place so it needs to watch those first 16 channels on the SCS-32 and
> correctly and smoothly switch control to the remote.
>
> No the question
> I know I can do this with the AT91SAM7X, it has the IO I need.
> a CLPD may be a better choice but I'm not as familure with them. I do
> have a Dev Kit to play with though
>
> Considering the setup, that data transfers are occurring etc..
> Which is in your opinions the best way to go? SAM7X or Xilinx?
> I will say based on my limited knowledge the SAM7X would appear to be
> better but I value your opinions
Tough call
You could likely achieve this with a SAMx using bitbang-style polling of the
RC channels. I managed to get a SAM7 running at 48MHz to crank over 400,000
interrupts per second (but not doing much else), you'd get even faster with
fiqs. The processing speed will constrain the resolution you get.
The FPGA option would give you the ability to make custom peripherals to do
the timing you need meaning that a less capable CPU could do what you want.
Another option: What about a Parallax Propeller chip? That is a eight-core
chip which could provide an interesting solution for a problem like this: 4
cores each handling 4 RC channels and another core doing the serial comms.
> Hi
>
> I'm looking at doing a project for some robotics work and want to
> provide autonomous operations but also with a RC override in case of
> issue's but also to allow for switching of RC to and from Autonomous
> operations
>
> Here's the setup
> I'm looking at a AT91SAM7X or a Xilinx CLPD to do this
> in is most basic form what I want to do is have it take as inputs
> up to 16 Channel's from a RC Receiver (direct from Servo outs) 1-2ms pulse
> and a SCS-32 Channel Servo Controller from Lynxmotion.
> the output would be 32 Channels with the first 16 Channels normally
> controlled by the SCS-32 (remaining 16 always controlled by the SCS-32)
> but by a flip of a switch on the RC remote (Gear switch for example) the
> controller will override the first 16 channels and begin sending the RC
> signals instead. flip the switch again and the SCS-32 is back in control.
>
> But also, I want it to read the 16 channels from the RC receiver and
> report position info on each channel via Serial interface (SPI/I2C or
> RS232)
> It also will need to do the switch in a safe manner. i.e. just switch
> may cause a motion more dangerous than what was happening in the first
> place so it needs to watch those first 16 channels on the SCS-32 and
> correctly and smoothly switch control to the remote.
>
> No the question
> I know I can do this with the AT91SAM7X, it has the IO I need.
> a CLPD may be a better choice but I'm not as familure with them. I do
> have a Dev Kit to play with though
>
> Considering the setup, that data transfers are occurring etc..
> Which is in your opinions the best way to go? SAM7X or Xilinx?
> I will say based on my limited knowledge the SAM7X would appear to be
> better but I value your opinions
Tough call
You could likely achieve this with a SAMx using bitbang-style polling of the
RC channels. I managed to get a SAM7 running at 48MHz to crank over 400,000
interrupts per second (but not doing much else), you'd get even faster with
fiqs. The processing speed will constrain the resolution you get.
The FPGA option would give you the ability to make custom peripherals to do
the timing you need meaning that a less capable CPU could do what you want.
Another option: What about a Parallax Propeller chip? That is a eight-core
chip which could provide an interesting solution for a problem like this: 4
cores each handling 4 RC channels and another core doing the serial comms.
Reply by ●August 28, 20082008-08-28
Sounds like you are making this way more confusing, OR, you are trying
to throw way more electronics at the problem than what is needed.
Why use the SSC-32 if you are going to use a SAM7X? Why not have the
SAM7X receive the serial commands, and internally generate the Servo
outputs based on the serial commands or 16 manual inputs (I assume the
other 16 are for some form of manual control.)
That eliminates a controller, and 16 connection lines.
You could still do this with a CPLD, but you would be better off using
SPI if possible. You would need a larger CPLD, but you should be able
to use the CPLD without the SSC-32 as well.
Depending on how many bits of resolution you want, the CPLD may come
up a bit short. If you have 16 channels of 8 bits resolution, you
will need 128 flip-flops (or logic gates) just to implement the PWM
outputs, add another 128 for PWM inputs, a very simple uart could be
hammed together in about 20 to 30 flip-flops, add another 16 or so for
a uart transmitter. Add an overall state machine, and you are looking
at the CPLD's in the 384 - 512 gate range. This CPLD cost from
DigiKey would be $22-$44.
The SAM7X would cost $11. If you let the micro-controller take the
place of the 16 SSC-32 inputs, you could by with an AVR or PIC in a 40
pin package, an ATMEGA164 goes for $4.80. If you want to stick with
ARM, a SAM7S321 will do it for $6.50.
John C
--- In A..., William Carroll wrote:
>
> Hi
>
> I'm looking at doing a project for some robotics work and want to
> provide autonomous operations but also with a RC override in case of
> issue's but also to allow for switching of RC to and from Autonomous
> operations
>
> Here's the setup
> I'm looking at a AT91SAM7X or a Xilinx CLPD to do this
> in is most basic form what I want to do is have it take as inputs
> up to 16 Channel's from a RC Receiver (direct from Servo outs)
1-2ms pulse
> and a SCS-32 Channel Servo Controller from Lynxmotion.
> the output would be 32 Channels with the first 16 Channels normally
> controlled by the SCS-32 (remaining 16 always controlled by the SCS-32)
> but by a flip of a switch on the RC remote (Gear switch for example)
the
> controller will override the first 16 channels and begin sending the RC
> signals instead. flip the switch again and the SCS-32 is back in
control.
>
> But also, I want it to read the 16 channels from the RC receiver and
> report position info on each channel via Serial interface (SPI/I2C or
> RS232)
> It also will need to do the switch in a safe manner. i.e. just switch
> may cause a motion more dangerous than what was happening in the
first place
> so it needs to watch those first 16 channels on the SCS-32 and
correctly
> and smoothly switch control to the remote.
>
> No the question
> I know I can do this with the AT91SAM7X, it has the IO I need.
> a CLPD may be a better choice but I'm not as familure with them. I do
> have a Dev Kit to play with though
>
> Considering the setup, that data transfers are occurring etc..
> Which is in your opinions the best way to go? SAM7X or Xilinx?
> I will say based on my limited knowledge the SAM7X would appear to be
> better but I value your opinions
>
> Thank you
> William Carroll
>
to throw way more electronics at the problem than what is needed.
Why use the SSC-32 if you are going to use a SAM7X? Why not have the
SAM7X receive the serial commands, and internally generate the Servo
outputs based on the serial commands or 16 manual inputs (I assume the
other 16 are for some form of manual control.)
That eliminates a controller, and 16 connection lines.
You could still do this with a CPLD, but you would be better off using
SPI if possible. You would need a larger CPLD, but you should be able
to use the CPLD without the SSC-32 as well.
Depending on how many bits of resolution you want, the CPLD may come
up a bit short. If you have 16 channels of 8 bits resolution, you
will need 128 flip-flops (or logic gates) just to implement the PWM
outputs, add another 128 for PWM inputs, a very simple uart could be
hammed together in about 20 to 30 flip-flops, add another 16 or so for
a uart transmitter. Add an overall state machine, and you are looking
at the CPLD's in the 384 - 512 gate range. This CPLD cost from
DigiKey would be $22-$44.
The SAM7X would cost $11. If you let the micro-controller take the
place of the 16 SSC-32 inputs, you could by with an AVR or PIC in a 40
pin package, an ATMEGA164 goes for $4.80. If you want to stick with
ARM, a SAM7S321 will do it for $6.50.
John C
--- In A..., William Carroll wrote:
>
> Hi
>
> I'm looking at doing a project for some robotics work and want to
> provide autonomous operations but also with a RC override in case of
> issue's but also to allow for switching of RC to and from Autonomous
> operations
>
> Here's the setup
> I'm looking at a AT91SAM7X or a Xilinx CLPD to do this
> in is most basic form what I want to do is have it take as inputs
> up to 16 Channel's from a RC Receiver (direct from Servo outs)
1-2ms pulse
> and a SCS-32 Channel Servo Controller from Lynxmotion.
> the output would be 32 Channels with the first 16 Channels normally
> controlled by the SCS-32 (remaining 16 always controlled by the SCS-32)
> but by a flip of a switch on the RC remote (Gear switch for example)
the
> controller will override the first 16 channels and begin sending the RC
> signals instead. flip the switch again and the SCS-32 is back in
control.
>
> But also, I want it to read the 16 channels from the RC receiver and
> report position info on each channel via Serial interface (SPI/I2C or
> RS232)
> It also will need to do the switch in a safe manner. i.e. just switch
> may cause a motion more dangerous than what was happening in the
first place
> so it needs to watch those first 16 channels on the SCS-32 and
correctly
> and smoothly switch control to the remote.
>
> No the question
> I know I can do this with the AT91SAM7X, it has the IO I need.
> a CLPD may be a better choice but I'm not as familure with them. I do
> have a Dev Kit to play with though
>
> Considering the setup, that data transfers are occurring etc..
> Which is in your opinions the best way to go? SAM7X or Xilinx?
> I will say based on my limited knowledge the SAM7X would appear to be
> better but I value your opinions
>
> Thank you
> William Carroll
>
Reply by ●August 28, 20082008-08-28
Thanks for the feedback,
The reason is the SCS-32 is already in use and I want to add a method to
override the SCS-32 with a RC Remote mainly for safety without having to
redo existing circuits
being able to plug in the 2 sources of servo signals and get the control
i want with a failsafe system
is what I'm after.
does that answer the why ok? does that at all change your view?
i welcome any more comments on this you or others may have
Thanks
William Carroll
John wrote:
>
> Sounds like you are making this way more confusing, OR, you are trying
> to throw way more electronics at the problem than what is needed.
>
> Why use the SSC-32 if you are going to use a SAM7X? Why not have the
> SAM7X receive the serial commands, and internally generate the Servo
> outputs based on the serial commands or 16 manual inputs (I assume the
> other 16 are for some form of manual control.)
>
> That eliminates a controller, and 16 connection lines.
>
> You could still do this with a CPLD, but you would be better off using
> SPI if possible. You would need a larger CPLD, but you should be able
> to use the CPLD without the SSC-32 as well.
>
> Depending on how many bits of resolution you want, the CPLD may come
> up a bit short. If you have 16 channels of 8 bits resolution, you
> will need 128 flip-flops (or logic gates) just to implement the PWM
> outputs, add another 128 for PWM inputs, a very simple uart could be
> hammed together in about 20 to 30 flip-flops, add another 16 or so for
> a uart transmitter. Add an overall state machine, and you are looking
> at the CPLD's in the 384 - 512 gate range. This CPLD cost from
> DigiKey would be $22-$44.
>
> The SAM7X would cost $11. If you let the micro-controller take the
> place of the 16 SSC-32 inputs, you could by with an AVR or PIC in a 40
> pin package, an ATMEGA164 goes for $4.80. If you want to stick with
> ARM, a SAM7S321 will do it for $6.50.
>
> John C
>
> --- In A... ,
> William Carroll wrote:
> >
> > Hi
> >
> > I'm looking at doing a project for some robotics work and want to
> > provide autonomous operations but also with a RC override in case of
> > issue's but also to allow for switching of RC to and from Autonomous
> > operations
> >
> > Here's the setup
> > I'm looking at a AT91SAM7X or a Xilinx CLPD to do this
> > in is most basic form what I want to do is have it take as inputs
> > up to 16 Channel's from a RC Receiver (direct from Servo outs)
> 1-2ms pulse
> > and a SCS-32 Channel Servo Controller from Lynxmotion.
> > the output would be 32 Channels with the first 16 Channels normally
> > controlled by the SCS-32 (remaining 16 always controlled by the SCS-32)
> > but by a flip of a switch on the RC remote (Gear switch for example)
> the
> > controller will override the first 16 channels and begin sending the RC
> > signals instead. flip the switch again and the SCS-32 is back in
> control.
> >
> > But also, I want it to read the 16 channels from the RC receiver and
> > report position info on each channel via Serial interface (SPI/I2C or
> > RS232)
> > It also will need to do the switch in a safe manner. i.e. just switch
> > may cause a motion more dangerous than what was happening in the
> first place
> > so it needs to watch those first 16 channels on the SCS-32 and
> correctly
> > and smoothly switch control to the remote.
> >
> > No the question
> > I know I can do this with the AT91SAM7X, it has the IO I need.
> > a CLPD may be a better choice but I'm not as familure with them. I do
> > have a Dev Kit to play with though
> >
> > Considering the setup, that data transfers are occurring etc..
> > Which is in your opinions the best way to go? SAM7X or Xilinx?
> > I will say based on my limited knowledge the SAM7X would appear to be
> > better but I value your opinions
> >
> > Thank you
> > William Carroll
> >
The reason is the SCS-32 is already in use and I want to add a method to
override the SCS-32 with a RC Remote mainly for safety without having to
redo existing circuits
being able to plug in the 2 sources of servo signals and get the control
i want with a failsafe system
is what I'm after.
does that answer the why ok? does that at all change your view?
i welcome any more comments on this you or others may have
Thanks
William Carroll
John wrote:
>
> Sounds like you are making this way more confusing, OR, you are trying
> to throw way more electronics at the problem than what is needed.
>
> Why use the SSC-32 if you are going to use a SAM7X? Why not have the
> SAM7X receive the serial commands, and internally generate the Servo
> outputs based on the serial commands or 16 manual inputs (I assume the
> other 16 are for some form of manual control.)
>
> That eliminates a controller, and 16 connection lines.
>
> You could still do this with a CPLD, but you would be better off using
> SPI if possible. You would need a larger CPLD, but you should be able
> to use the CPLD without the SSC-32 as well.
>
> Depending on how many bits of resolution you want, the CPLD may come
> up a bit short. If you have 16 channels of 8 bits resolution, you
> will need 128 flip-flops (or logic gates) just to implement the PWM
> outputs, add another 128 for PWM inputs, a very simple uart could be
> hammed together in about 20 to 30 flip-flops, add another 16 or so for
> a uart transmitter. Add an overall state machine, and you are looking
> at the CPLD's in the 384 - 512 gate range. This CPLD cost from
> DigiKey would be $22-$44.
>
> The SAM7X would cost $11. If you let the micro-controller take the
> place of the 16 SSC-32 inputs, you could by with an AVR or PIC in a 40
> pin package, an ATMEGA164 goes for $4.80. If you want to stick with
> ARM, a SAM7S321 will do it for $6.50.
>
> John C
>
> --- In A... ,
> William Carroll wrote:
> >
> > Hi
> >
> > I'm looking at doing a project for some robotics work and want to
> > provide autonomous operations but also with a RC override in case of
> > issue's but also to allow for switching of RC to and from Autonomous
> > operations
> >
> > Here's the setup
> > I'm looking at a AT91SAM7X or a Xilinx CLPD to do this
> > in is most basic form what I want to do is have it take as inputs
> > up to 16 Channel's from a RC Receiver (direct from Servo outs)
> 1-2ms pulse
> > and a SCS-32 Channel Servo Controller from Lynxmotion.
> > the output would be 32 Channels with the first 16 Channels normally
> > controlled by the SCS-32 (remaining 16 always controlled by the SCS-32)
> > but by a flip of a switch on the RC remote (Gear switch for example)
> the
> > controller will override the first 16 channels and begin sending the RC
> > signals instead. flip the switch again and the SCS-32 is back in
> control.
> >
> > But also, I want it to read the 16 channels from the RC receiver and
> > report position info on each channel via Serial interface (SPI/I2C or
> > RS232)
> > It also will need to do the switch in a safe manner. i.e. just switch
> > may cause a motion more dangerous than what was happening in the
> first place
> > so it needs to watch those first 16 channels on the SCS-32 and
> correctly
> > and smoothly switch control to the remote.
> >
> > No the question
> > I know I can do this with the AT91SAM7X, it has the IO I need.
> > a CLPD may be a better choice but I'm not as familure with them. I do
> > have a Dev Kit to play with though
> >
> > Considering the setup, that data transfers are occurring etc..
> > Which is in your opinions the best way to go? SAM7X or Xilinx?
> > I will say based on my limited knowledge the SAM7X would appear to be
> > better but I value your opinions
> >
> > Thank you
> > William Carroll
> >
Reply by ●August 29, 20082008-08-29
So, do are you going to use an actual 32 position switch to toggle
things, or is the CPLD/SAM7X supposed to transition from one set to
the other?
If the CPLD/SAM7X is supposed to gracefully transition between
automatic and manual control, then the CPLD will likely come up short.
If you are looking to make an "intelligent" relay, then the CPLD will
likely work best, you could use a fairly cheap and brain-dead CPLD for
that.
If you want the CPLD/SAM7X to monitor it's inputs to provide commanded
position feedback, then it gets iffy with a CPLD and starts to look
like something better accomplished with a small gate count FPGA.
John C
--- In A..., William Carroll wrote:
>
> Thanks for the feedback,
>
> The reason is the SCS-32 is already in use and I want to add a method to
> override the SCS-32 with a RC Remote mainly for safety without
having to
> redo existing circuits
> being able to plug in the 2 sources of servo signals and get the
control
> i want with a failsafe system
> is what I'm after.
>
> does that answer the why ok? does that at all change your view?
>
> i welcome any more comments on this you or others may have
>
> Thanks
> William Carroll
> John wrote:
> >
> > Sounds like you are making this way more confusing, OR, you are trying
> > to throw way more electronics at the problem than what is needed.
> >
> > Why use the SSC-32 if you are going to use a SAM7X? Why not have the
> > SAM7X receive the serial commands, and internally generate the Servo
> > outputs based on the serial commands or 16 manual inputs (I assume the
> > other 16 are for some form of manual control.)
> >
> > That eliminates a controller, and 16 connection lines.
> >
> > You could still do this with a CPLD, but you would be better off using
> > SPI if possible. You would need a larger CPLD, but you should be able
> > to use the CPLD without the SSC-32 as well.
> >
> > Depending on how many bits of resolution you want, the CPLD may come
> > up a bit short. If you have 16 channels of 8 bits resolution, you
> > will need 128 flip-flops (or logic gates) just to implement the PWM
> > outputs, add another 128 for PWM inputs, a very simple uart could be
> > hammed together in about 20 to 30 flip-flops, add another 16 or so for
> > a uart transmitter. Add an overall state machine, and you are looking
> > at the CPLD's in the 384 - 512 gate range. This CPLD cost from
> > DigiKey would be $22-$44.
> >
> > The SAM7X would cost $11. If you let the micro-controller take the
> > place of the 16 SSC-32 inputs, you could by with an AVR or PIC in a 40
> > pin package, an ATMEGA164 goes for $4.80. If you want to stick with
> > ARM, a SAM7S321 will do it for $6.50.
> >
> > John C
> >
> > --- In A... ,
> > William Carroll wrote:
> > >
> > > Hi
> > >
> > > I'm looking at doing a project for some robotics work and want to
> > > provide autonomous operations but also with a RC override in case of
> > > issue's but also to allow for switching of RC to and from Autonomous
> > > operations
> > >
> > > Here's the setup
> > > I'm looking at a AT91SAM7X or a Xilinx CLPD to do this
> > > in is most basic form what I want to do is have it take as inputs
> > > up to 16 Channel's from a RC Receiver (direct from Servo outs)
> > 1-2ms pulse
> > > and a SCS-32 Channel Servo Controller from Lynxmotion.
> > > the output would be 32 Channels with the first 16 Channels normally
> > > controlled by the SCS-32 (remaining 16 always controlled by the
SCS-32)
> > > but by a flip of a switch on the RC remote (Gear switch for example)
> > the
> > > controller will override the first 16 channels and begin sending
the RC
> > > signals instead. flip the switch again and the SCS-32 is back in
> > control.
> > >
> > > But also, I want it to read the 16 channels from the RC receiver and
> > > report position info on each channel via Serial interface
(SPI/I2C or
> > > RS232)
> > > It also will need to do the switch in a safe manner. i.e. just
switch
> > > may cause a motion more dangerous than what was happening in the
> > first place
> > > so it needs to watch those first 16 channels on the SCS-32 and
> > correctly
> > > and smoothly switch control to the remote.
> > >
> > > No the question
> > > I know I can do this with the AT91SAM7X, it has the IO I need.
> > > a CLPD may be a better choice but I'm not as familure with them.
I do
> > > have a Dev Kit to play with though
> > >
> > > Considering the setup, that data transfers are occurring etc..
> > > Which is in your opinions the best way to go? SAM7X or Xilinx?
> > > I will say based on my limited knowledge the SAM7X would appear
to be
> > > better but I value your opinions
> > >
> > > Thank you
> > > William Carroll
> > >
> >
>
things, or is the CPLD/SAM7X supposed to transition from one set to
the other?
If the CPLD/SAM7X is supposed to gracefully transition between
automatic and manual control, then the CPLD will likely come up short.
If you are looking to make an "intelligent" relay, then the CPLD will
likely work best, you could use a fairly cheap and brain-dead CPLD for
that.
If you want the CPLD/SAM7X to monitor it's inputs to provide commanded
position feedback, then it gets iffy with a CPLD and starts to look
like something better accomplished with a small gate count FPGA.
John C
--- In A..., William Carroll wrote:
>
> Thanks for the feedback,
>
> The reason is the SCS-32 is already in use and I want to add a method to
> override the SCS-32 with a RC Remote mainly for safety without
having to
> redo existing circuits
> being able to plug in the 2 sources of servo signals and get the
control
> i want with a failsafe system
> is what I'm after.
>
> does that answer the why ok? does that at all change your view?
>
> i welcome any more comments on this you or others may have
>
> Thanks
> William Carroll
> John wrote:
> >
> > Sounds like you are making this way more confusing, OR, you are trying
> > to throw way more electronics at the problem than what is needed.
> >
> > Why use the SSC-32 if you are going to use a SAM7X? Why not have the
> > SAM7X receive the serial commands, and internally generate the Servo
> > outputs based on the serial commands or 16 manual inputs (I assume the
> > other 16 are for some form of manual control.)
> >
> > That eliminates a controller, and 16 connection lines.
> >
> > You could still do this with a CPLD, but you would be better off using
> > SPI if possible. You would need a larger CPLD, but you should be able
> > to use the CPLD without the SSC-32 as well.
> >
> > Depending on how many bits of resolution you want, the CPLD may come
> > up a bit short. If you have 16 channels of 8 bits resolution, you
> > will need 128 flip-flops (or logic gates) just to implement the PWM
> > outputs, add another 128 for PWM inputs, a very simple uart could be
> > hammed together in about 20 to 30 flip-flops, add another 16 or so for
> > a uart transmitter. Add an overall state machine, and you are looking
> > at the CPLD's in the 384 - 512 gate range. This CPLD cost from
> > DigiKey would be $22-$44.
> >
> > The SAM7X would cost $11. If you let the micro-controller take the
> > place of the 16 SSC-32 inputs, you could by with an AVR or PIC in a 40
> > pin package, an ATMEGA164 goes for $4.80. If you want to stick with
> > ARM, a SAM7S321 will do it for $6.50.
> >
> > John C
> >
> > --- In A... ,
> > William Carroll wrote:
> > >
> > > Hi
> > >
> > > I'm looking at doing a project for some robotics work and want to
> > > provide autonomous operations but also with a RC override in case of
> > > issue's but also to allow for switching of RC to and from Autonomous
> > > operations
> > >
> > > Here's the setup
> > > I'm looking at a AT91SAM7X or a Xilinx CLPD to do this
> > > in is most basic form what I want to do is have it take as inputs
> > > up to 16 Channel's from a RC Receiver (direct from Servo outs)
> > 1-2ms pulse
> > > and a SCS-32 Channel Servo Controller from Lynxmotion.
> > > the output would be 32 Channels with the first 16 Channels normally
> > > controlled by the SCS-32 (remaining 16 always controlled by the
SCS-32)
> > > but by a flip of a switch on the RC remote (Gear switch for example)
> > the
> > > controller will override the first 16 channels and begin sending
the RC
> > > signals instead. flip the switch again and the SCS-32 is back in
> > control.
> > >
> > > But also, I want it to read the 16 channels from the RC receiver and
> > > report position info on each channel via Serial interface
(SPI/I2C or
> > > RS232)
> > > It also will need to do the switch in a safe manner. i.e. just
switch
> > > may cause a motion more dangerous than what was happening in the
> > first place
> > > so it needs to watch those first 16 channels on the SCS-32 and
> > correctly
> > > and smoothly switch control to the remote.
> > >
> > > No the question
> > > I know I can do this with the AT91SAM7X, it has the IO I need.
> > > a CLPD may be a better choice but I'm not as familure with them.
I do
> > > have a Dev Kit to play with though
> > >
> > > Considering the setup, that data transfers are occurring etc..
> > > Which is in your opinions the best way to go? SAM7X or Xilinx?
> > > I will say based on my limited knowledge the SAM7X would appear
to be
> > > better but I value your opinions
> > >
> > > Thank you
> > > William Carroll
> > >
> >
>
Reply by ●August 29, 20082008-08-29
Out of the 32 servos the 16 that are not controllable by the RC would
return to a failsafe position
of the 16 that could be RC controlled. I'm looking to move some into an
off position (i.e. doors, arms etc..)
while I'm looking for a smoother (safer) control for the throttle and
direction. so 2 channels would need
the smooth transition and the rest can go to their failsafe.
this is part of why I wanted to send position data so the autonomous
controller can sense
these changes in position and update itself for when control returns.
William Carroll
John wrote:
>
> So, do are you going to use an actual 32 position switch to toggle
> things, or is the CPLD/SAM7X supposed to transition from one set to
> the other?
>
> If the CPLD/SAM7X is supposed to gracefully transition between
> automatic and manual control, then the CPLD will likely come up short.
> If you are looking to make an "intelligent" relay, then the CPLD will
> likely work best, you could use a fairly cheap and brain-dead CPLD for
> that.
>
> If you want the CPLD/SAM7X to monitor it's inputs to provide commanded
> position feedback, then it gets iffy with a CPLD and starts to look
> like something better accomplished with a small gate count FPGA.
>
> John C
>
> --- In A... ,
> William Carroll wrote:
> >
> > Thanks for the feedback,
> >
> > The reason is the SCS-32 is already in use and I want to add a method to
> > override the SCS-32 with a RC Remote mainly for safety without
> having to
> > redo existing circuits
> > being able to plug in the 2 sources of servo signals and get the
> control
> > i want with a failsafe system
> > is what I'm after.
> >
> > does that answer the why ok? does that at all change your view?
> >
> > i welcome any more comments on this you or others may have
> >
> > Thanks
> > William Carroll
> >
> >
> > John wrote:
> > >
> > > Sounds like you are making this way more confusing, OR, you are trying
> > > to throw way more electronics at the problem than what is needed.
> > >
> > > Why use the SSC-32 if you are going to use a SAM7X? Why not have the
> > > SAM7X receive the serial commands, and internally generate the Servo
> > > outputs based on the serial commands or 16 manual inputs (I assume the
> > > other 16 are for some form of manual control.)
> > >
> > > That eliminates a controller, and 16 connection lines.
> > >
> > > You could still do this with a CPLD, but you would be better off using
> > > SPI if possible. You would need a larger CPLD, but you should be able
> > > to use the CPLD without the SSC-32 as well.
> > >
> > > Depending on how many bits of resolution you want, the CPLD may come
> > > up a bit short. If you have 16 channels of 8 bits resolution, you
> > > will need 128 flip-flops (or logic gates) just to implement the PWM
> > > outputs, add another 128 for PWM inputs, a very simple uart could be
> > > hammed together in about 20 to 30 flip-flops, add another 16 or so for
> > > a uart transmitter. Add an overall state machine, and you are looking
> > > at the CPLD's in the 384 - 512 gate range. This CPLD cost from
> > > DigiKey would be $22-$44.
> > >
> > > The SAM7X would cost $11. If you let the micro-controller take the
> > > place of the 16 SSC-32 inputs, you could by with an AVR or PIC in a 40
> > > pin package, an ATMEGA164 goes for $4.80. If you want to stick with
> > > ARM, a SAM7S321 will do it for $6.50.
> > >
> > > John C
> > >
> > > --- In A...
> ,
> > > William Carroll wrote:
> > > >
> > > > Hi
> > > >
> > > > I'm looking at doing a project for some robotics work and want to
> > > > provide autonomous operations but also with a RC override in case of
> > > > issue's but also to allow for switching of RC to and from Autonomous
> > > > operations
> > > >
> > > > Here's the setup
> > > > I'm looking at a AT91SAM7X or a Xilinx CLPD to do this
> > > > in is most basic form what I want to do is have it take as inputs
> > > > up to 16 Channel's from a RC Receiver (direct from Servo outs)
> > > 1-2ms pulse
> > > > and a SCS-32 Channel Servo Controller from Lynxmotion.
> > > > the output would be 32 Channels with the first 16 Channels normally
> > > > controlled by the SCS-32 (remaining 16 always controlled by the
> SCS-32)
> > > > but by a flip of a switch on the RC remote (Gear switch for example)
> > > the
> > > > controller will override the first 16 channels and begin sending
> the RC
> > > > signals instead. flip the switch again and the SCS-32 is back in
> > > control.
> > > >
> > > > But also, I want it to read the 16 channels from the RC receiver and
> > > > report position info on each channel via Serial interface
> (SPI/I2C or
> > > > RS232)
> > > > It also will need to do the switch in a safe manner. i.e. just
> switch
> > > > may cause a motion more dangerous than what was happening in the
> > > first place
> > > > so it needs to watch those first 16 channels on the SCS-32 and
> > > correctly
> > > > and smoothly switch control to the remote.
> > > >
> > > > No the question
> > > > I know I can do this with the AT91SAM7X, it has the IO I need.
> > > > a CLPD may be a better choice but I'm not as familure with them.
> I do
> > > > have a Dev Kit to play with though
> > > >
> > > > Considering the setup, that data transfers are occurring etc..
> > > > Which is in your opinions the best way to go? SAM7X or Xilinx?
> > > > I will say based on my limited knowledge the SAM7X would appear
> to be
> > > > better but I value your opinions
> > > >
> > > > Thank you
> > > > William Carroll
> > > >
> > >
> > >
> >
return to a failsafe position
of the 16 that could be RC controlled. I'm looking to move some into an
off position (i.e. doors, arms etc..)
while I'm looking for a smoother (safer) control for the throttle and
direction. so 2 channels would need
the smooth transition and the rest can go to their failsafe.
this is part of why I wanted to send position data so the autonomous
controller can sense
these changes in position and update itself for when control returns.
William Carroll
John wrote:
>
> So, do are you going to use an actual 32 position switch to toggle
> things, or is the CPLD/SAM7X supposed to transition from one set to
> the other?
>
> If the CPLD/SAM7X is supposed to gracefully transition between
> automatic and manual control, then the CPLD will likely come up short.
> If you are looking to make an "intelligent" relay, then the CPLD will
> likely work best, you could use a fairly cheap and brain-dead CPLD for
> that.
>
> If you want the CPLD/SAM7X to monitor it's inputs to provide commanded
> position feedback, then it gets iffy with a CPLD and starts to look
> like something better accomplished with a small gate count FPGA.
>
> John C
>
> --- In A... ,
> William Carroll wrote:
> >
> > Thanks for the feedback,
> >
> > The reason is the SCS-32 is already in use and I want to add a method to
> > override the SCS-32 with a RC Remote mainly for safety without
> having to
> > redo existing circuits
> > being able to plug in the 2 sources of servo signals and get the
> control
> > i want with a failsafe system
> > is what I'm after.
> >
> > does that answer the why ok? does that at all change your view?
> >
> > i welcome any more comments on this you or others may have
> >
> > Thanks
> > William Carroll
> >
> >
> > John wrote:
> > >
> > > Sounds like you are making this way more confusing, OR, you are trying
> > > to throw way more electronics at the problem than what is needed.
> > >
> > > Why use the SSC-32 if you are going to use a SAM7X? Why not have the
> > > SAM7X receive the serial commands, and internally generate the Servo
> > > outputs based on the serial commands or 16 manual inputs (I assume the
> > > other 16 are for some form of manual control.)
> > >
> > > That eliminates a controller, and 16 connection lines.
> > >
> > > You could still do this with a CPLD, but you would be better off using
> > > SPI if possible. You would need a larger CPLD, but you should be able
> > > to use the CPLD without the SSC-32 as well.
> > >
> > > Depending on how many bits of resolution you want, the CPLD may come
> > > up a bit short. If you have 16 channels of 8 bits resolution, you
> > > will need 128 flip-flops (or logic gates) just to implement the PWM
> > > outputs, add another 128 for PWM inputs, a very simple uart could be
> > > hammed together in about 20 to 30 flip-flops, add another 16 or so for
> > > a uart transmitter. Add an overall state machine, and you are looking
> > > at the CPLD's in the 384 - 512 gate range. This CPLD cost from
> > > DigiKey would be $22-$44.
> > >
> > > The SAM7X would cost $11. If you let the micro-controller take the
> > > place of the 16 SSC-32 inputs, you could by with an AVR or PIC in a 40
> > > pin package, an ATMEGA164 goes for $4.80. If you want to stick with
> > > ARM, a SAM7S321 will do it for $6.50.
> > >
> > > John C
> > >
> > > --- In A...
> ,
> > > William Carroll wrote:
> > > >
> > > > Hi
> > > >
> > > > I'm looking at doing a project for some robotics work and want to
> > > > provide autonomous operations but also with a RC override in case of
> > > > issue's but also to allow for switching of RC to and from Autonomous
> > > > operations
> > > >
> > > > Here's the setup
> > > > I'm looking at a AT91SAM7X or a Xilinx CLPD to do this
> > > > in is most basic form what I want to do is have it take as inputs
> > > > up to 16 Channel's from a RC Receiver (direct from Servo outs)
> > > 1-2ms pulse
> > > > and a SCS-32 Channel Servo Controller from Lynxmotion.
> > > > the output would be 32 Channels with the first 16 Channels normally
> > > > controlled by the SCS-32 (remaining 16 always controlled by the
> SCS-32)
> > > > but by a flip of a switch on the RC remote (Gear switch for example)
> > > the
> > > > controller will override the first 16 channels and begin sending
> the RC
> > > > signals instead. flip the switch again and the SCS-32 is back in
> > > control.
> > > >
> > > > But also, I want it to read the 16 channels from the RC receiver and
> > > > report position info on each channel via Serial interface
> (SPI/I2C or
> > > > RS232)
> > > > It also will need to do the switch in a safe manner. i.e. just
> switch
> > > > may cause a motion more dangerous than what was happening in the
> > > first place
> > > > so it needs to watch those first 16 channels on the SCS-32 and
> > > correctly
> > > > and smoothly switch control to the remote.
> > > >
> > > > No the question
> > > > I know I can do this with the AT91SAM7X, it has the IO I need.
> > > > a CLPD may be a better choice but I'm not as familure with them.
> I do
> > > > have a Dev Kit to play with though
> > > >
> > > > Considering the setup, that data transfers are occurring etc..
> > > > Which is in your opinions the best way to go? SAM7X or Xilinx?
> > > > I will say based on my limited knowledge the SAM7X would appear
> to be
> > > > better but I value your opinions
> > > >
> > > > Thank you
> > > > William Carroll
> > > >
> > >
> > >
> >
Reply by ●September 5, 20082008-09-05
With the help of engineers at Atmel, we have solved this problem, and
I want to post a followup.
The problem in the end turned out to be the Flash Microsecond Cycle
Number (see FMCN, spec page 113).
The spec reads as follows:
> FMCN: Flash Microsecond Cycle Number
> Before writing Non Volatile Memory bits (Lock bits, General Purpose NVM
> bit and Security bits), this field must be set to the number of Master
> Clock cycles in one microsecond.
>
> When writing the rest of the Flash, this field defines the number of
Master
> Clock cycles in 1.5 microseconds. This number must be rounded up.
> Warning: The value 0 is only allowed for a master clock period
superior to
> 30 microseconds.
>
> Warning: In order to guarantee valid operations on the flash memory,
> the field Flash Microsecond Cycle Number (FMCN) must be correctly
> programmed.
But if you look at the macro provided in lib_AT91SAM7X256.h,
>
//*----
> //* \fn AT91F_MC_EFC_ComputeFMCN
> //* \brief Return MC EFC Mode Regsiter
>
//*----
> __inline unsigned int AT91F_MC_EFC_ComputeFMCN(
> int master_clock) // master clock in Hz
> {
> return (master_clock/1000000 +2);
> }
Clearly there is a disconnect here between the spec and the header
file. Using the macro, our 55MHz master clock calls for a value of 57
for the FMCN, but the spec says this would be only for writing the
GPNVM and lock bits. To write flash, we should use a value of 83 ...
but that macro would never result in 83!
Because of this, we had been using 57 for both flash operations. This
is apparently VERY BAD. There are a certain percentage of chips that
can handle using that value, and the rest cannot - the flash will be
damaged. This was confirmed by Atmel engineering. We sampled 4 of
the 0831 date code, and were able to make 1 fail with the wrong FMCN
value.
Now that we have made the change to set the other FMCN value right
before writing the flash pages, things are working perfectly. I have
burned 14 out of 14 attempts successfully.
Our recommendation is to follow the spec and create the values by
hand, and use them where appropriate. Do not rely on the macro.
So, it turns out that code really can cause hardware damage!
I want to post a followup.
The problem in the end turned out to be the Flash Microsecond Cycle
Number (see FMCN, spec page 113).
The spec reads as follows:
> FMCN: Flash Microsecond Cycle Number
> Before writing Non Volatile Memory bits (Lock bits, General Purpose NVM
> bit and Security bits), this field must be set to the number of Master
> Clock cycles in one microsecond.
>
> When writing the rest of the Flash, this field defines the number of
Master
> Clock cycles in 1.5 microseconds. This number must be rounded up.
> Warning: The value 0 is only allowed for a master clock period
superior to
> 30 microseconds.
>
> Warning: In order to guarantee valid operations on the flash memory,
> the field Flash Microsecond Cycle Number (FMCN) must be correctly
> programmed.
But if you look at the macro provided in lib_AT91SAM7X256.h,
>
//*----
> //* \fn AT91F_MC_EFC_ComputeFMCN
> //* \brief Return MC EFC Mode Regsiter
>
//*----
> __inline unsigned int AT91F_MC_EFC_ComputeFMCN(
> int master_clock) // master clock in Hz
> {
> return (master_clock/1000000 +2);
> }
Clearly there is a disconnect here between the spec and the header
file. Using the macro, our 55MHz master clock calls for a value of 57
for the FMCN, but the spec says this would be only for writing the
GPNVM and lock bits. To write flash, we should use a value of 83 ...
but that macro would never result in 83!
Because of this, we had been using 57 for both flash operations. This
is apparently VERY BAD. There are a certain percentage of chips that
can handle using that value, and the rest cannot - the flash will be
damaged. This was confirmed by Atmel engineering. We sampled 4 of
the 0831 date code, and were able to make 1 fail with the wrong FMCN
value.
Now that we have made the change to set the other FMCN value right
before writing the flash pages, things are working perfectly. I have
burned 14 out of 14 attempts successfully.
Our recommendation is to follow the spec and create the values by
hand, and use them where appropriate. Do not rely on the macro.
So, it turns out that code really can cause hardware damage!
