Do you have a good EMI lab near you?
To truly resolve this problem, you will need an engineer that is
well versed in EMC COMPLIANCE (FCC or CE/EN) and a good lab with
proper tools, a range (indoor or outdoor), etc. These are items such
as spectrum analyzers, proper antennas, properly calibrated and
verified by the lab's records.
I put very little credibility in determining by scanner or other
"cheap" methods that there is a problem in just the 150MHz radio.
This is because RF may be the balloon mentioned, and your fixes will
cause problems with other essential devices.
By the way, switching power shouldn't show at 150MHz, since most I
know are switching between 20kHz to 200kHz (maybe 1MHz) and if built
correctly, should have spurs only visible on a spectrum analyzer up
to odd multiples of MAYBE 15MHz (and very low amplitudes, at that).
MAX 232 devices are similar. Rabbit, depending on clock speed, should
be visible on odd harmonics of the crytal oscillator (22MHz, 29.4MHz,
etc.), since most of the switching there is high level. The internal
doubler should give minimal noise. By rough calculation, 22.1MHz has
a fifth harmonic of 110.5MHz and 29.4MHz has a fifth harmonic of
145.9MHz, which if strong enough, could be talking into the IF stages
of the radio, as well as the antenna, depending on the radio
construction and shielding.
To resolve, I recommend capacitors between power and ground pins on
all the memory, peripherals, etc. Do not use silly rules such as
0.1uF per 2 74LS/74HC devices, put one on ALL chips. On devices with
mutiple power and ground pins, one cap per pair may be needed. If you
use ferrites, they must meet the current requirements of your
devices, and are best in PI or L filters. THere may be a specially
designed box that is a power inlet, similar to those line filters for
AC power. In fact, they may also be called line filters. On the
outside, I recommend that the power go through a differrential choke
(toroidal ferrite with both plus voltage and ground fed through it,
and close to the device. The radio may also need this type choke on
its power lines. From my experience, grounds are what you have to
make them, continuous or not, but all must come together at the power
supply ground input to the box. Depending on ADC/DAC preferences in
the data sheet, you may find reference to localized separate ground
layouts.
Look for application notes on EMC/EMI component web pages, Intel
notes, other IC maker web pages, etc. and anything else you can think
of. Ham Radio literature is helpful here, as well, especially
regarding mobile installations.
And also as stated before, GOOD LUCK!!!
--- In rabbit-semi@rabb..., Mike van Meeteren <mike@f...>
wrote:
> Guys,
>
> I'm having a problem with our RCM3000 equipped product generating
RFI
> interference. Our product is a piece of
electronics that is
installed in
> DOT style snow removal equipment, and it
interferes with their
business
> band two way radios when they use frequencies
close to the RFI
generated by
> the Rabbit core.
>
> We had a radio guy work with our equipment and determined with a
frequency
> counter that the biggest signal was at 151.0688
MHz. Our entire
> electronics package is enclosed in a grounded die cast aluminum
case, with
> several connectors to the outside of the box
(including the
ethernet jack
> on the core). From previous testing it appears to
be bleeding out
over a
> 9600 baud serial cable, which seems odd. I assume
that the signal
must be
> seeping out over the ground plane. The only thing
that runs at
anything
> close to that frequency is the clock on the Rabbit
Core. Most of
the other
> stuff is in the KHz range.
>
> We're going to try to use some clamp on ferrite beads to solve the
problem,
> but I'd like to hear if anyone else has had
problems with this type
of
> noise, and what they did to solve the problem.
>
> Thanks in advance!
>
> -Mike
RCM3000 generates RFI noise
Started by ●September 27, 2005
Reply by ●September 27, 20052005-09-27
Reply by ●September 27, 20052005-09-27
I believe the switcher to be less likely as the cause of noise at
151MHz. Properly designed and laid out switching power supplies
should have toroids (containing more of the field) and proper
capacitance. The FET and control/switching circuits should be clamped
for the inductive back voltage. Each device should be bypassed
correctly, per applications information for the part or from
experience.
I still suggest getting an experienced engineer, versed in the black
arts of EMC, etc. to help.
--- In rabbit-semi@rabb..., Scott Henion <shenion@s...> wrote:
> At 12:08 PM 9/27/2005, you wrote:
> >You dismiss the switcher because it's 20khz, but the actual time it
> >spends between on and off is usually quite short (to improve
> >efficiency), and this transition can generate tremendous RF if not
> >bypassed right. Look closely here.
>
> That is true. The on time for 12V-5V would normally be 20-30%. That
> would generate pulses in that range.
>
> Also you should have a snubber on the coil when the switcher
operates
> on lower currents than optimal. When the current drops to 0 near
the
> end of the cycle, the voltage can collapse and the coil/MOSFET
> capacitanc make a nice resonant circuit that oscillates at high
frequencies.
>
> Poor layout of the gate of the FET can also cause oscillation at
turn
> on. Sometimes a small resistor on the gate can help reduce
> oscillations. It will switch a bit slower, but it is usually more
> efficient than oscillating. > ------
> | Scott G. Henion| shenion@s... |
> | Consultant | Stone Mountain, GA |
> | SHDesigns | PGP Key 0xE98DDC48 |
> | http://www.shdesigns.org |
> ------
> today's fortune
> Man is a rational animal who always loses his temper when he is
called upon
> to act in accordance with the dictates of reason.
> -- Oscar Wilde > --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.344 / Virus Database: 267.11.7/112 - Release Date:
9/26/2005
151MHz. Properly designed and laid out switching power supplies
should have toroids (containing more of the field) and proper
capacitance. The FET and control/switching circuits should be clamped
for the inductive back voltage. Each device should be bypassed
correctly, per applications information for the part or from
experience.
I still suggest getting an experienced engineer, versed in the black
arts of EMC, etc. to help.
--- In rabbit-semi@rabb..., Scott Henion <shenion@s...> wrote:
> At 12:08 PM 9/27/2005, you wrote:
> >You dismiss the switcher because it's 20khz, but the actual time it
> >spends between on and off is usually quite short (to improve
> >efficiency), and this transition can generate tremendous RF if not
> >bypassed right. Look closely here.
>
> That is true. The on time for 12V-5V would normally be 20-30%. That
> would generate pulses in that range.
>
> Also you should have a snubber on the coil when the switcher
operates
> on lower currents than optimal. When the current drops to 0 near
the
> end of the cycle, the voltage can collapse and the coil/MOSFET
> capacitanc make a nice resonant circuit that oscillates at high
frequencies.
>
> Poor layout of the gate of the FET can also cause oscillation at
turn
> on. Sometimes a small resistor on the gate can help reduce
> oscillations. It will switch a bit slower, but it is usually more
> efficient than oscillating. > ------
> | Scott G. Henion| shenion@s... |
> | Consultant | Stone Mountain, GA |
> | SHDesigns | PGP Key 0xE98DDC48 |
> | http://www.shdesigns.org |
> ------
> today's fortune
> Man is a rational animal who always loses his temper when he is
called upon
> to act in accordance with the dictates of reason.
> -- Oscar Wilde > --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.344 / Virus Database: 267.11.7/112 - Release Date:
9/26/2005
Reply by ●September 27, 20052005-09-27
Mike,
Best tip I ever got on the topic: Pinpoint the source of the noise, and
kill it as close to the source as possible. It will often emanate from a
completely unexpected place (kudos to the guys who brought up the regulator
and MAX232 chips).
My technique was to build a "sniffer" probe and go snooping around the board
with a high-speed scope (like my TEK 475, which you're always welcome to
borrow). The sniffer is nothing but a piece of coaxial cable with a really
tiny (like 0.125") loop of wire at the end.
Poking around the board with a probe like that can show you a lot, and
you'll have to be right on top of the source to see it.
In one design I worked on, I found a spot on a board near a fast (for its
day) A/D converter which had no business emanating anything near the
frequency it was throwing... 20MHz or so. We found that by cutting part of
the ground plane and bypassing it right next to the part, we cut the noise
almost completely. Turned out that one key bypass cap was indeed shunting
most of the 20MHz noise to the ground plane, but that cap was a couple of
inches from the offending part. The ground plane, of course, still carried
the current, and acted like a nice little antenna!
Good luck "sniffing" this one out, Mike.
Rob--- LapTwo Technologies, LLC
554 3rd St Northwest
Elk River, Minnesota 55330-1416
+1-763-633-LAP2 (5272)
Best tip I ever got on the topic: Pinpoint the source of the noise, and
kill it as close to the source as possible. It will often emanate from a
completely unexpected place (kudos to the guys who brought up the regulator
and MAX232 chips).
My technique was to build a "sniffer" probe and go snooping around the board
with a high-speed scope (like my TEK 475, which you're always welcome to
borrow). The sniffer is nothing but a piece of coaxial cable with a really
tiny (like 0.125") loop of wire at the end.
Poking around the board with a probe like that can show you a lot, and
you'll have to be right on top of the source to see it.
In one design I worked on, I found a spot on a board near a fast (for its
day) A/D converter which had no business emanating anything near the
frequency it was throwing... 20MHz or so. We found that by cutting part of
the ground plane and bypassing it right next to the part, we cut the noise
almost completely. Turned out that one key bypass cap was indeed shunting
most of the 20MHz noise to the ground plane, but that cap was a couple of
inches from the offending part. The ground plane, of course, still carried
the current, and acted like a nice little antenna!
Good luck "sniffing" this one out, Mike.
Rob--- LapTwo Technologies, LLC
554 3rd St Northwest
Elk River, Minnesota 55330-1416
+1-763-633-LAP2 (5272)
Reply by ●September 27, 20052005-09-27
At 01:11 PM 9/27/2005, you wrote:
>I believe the switcher to be less likely as the cause of noise at
>151MHz.
That is not what I have seen. Although most I have seen with problems
were in the 20-30mHz range.
> Properly designed and laid out switching power supplies
>should have toroids (containing more of the field) and proper
>capacitance.
Toroids help with magnetic fields. For these small designs with a
sufficient ground plane, the surface-mount coils work well.
> The FET and control/switching circuits should be clamped
>for the inductive back voltage. Each device should be bypassed
>correctly, per applications information for the part or from
>experience.
I have seen HF noise on switching designs I have had to fix these
problems on. One of them was 24v/5A that ran at 20kHZ. That
broadacast a huge signal at about 27 mHz and also at 65mHz.
65MHz was the resonant frequency of the coil and stray capacitance.
There was no snubber to prevent this oscillation.
27MHz was the big problem, someone decided to move the MOSFETs to the
opposite side of the heatsink to improve assembly. This increased the
gate/drain length. The inductance of the leads caused the MOSFET to
oscillate at 27mHz at turn on. A 3 amp 27mHz signal radiated quite
well ;). Increasing the trace width drastically helped (freq went to
33mHz but was far less oscillation.) Increasing the gate drive
capability and then adding a very small resistor to the gate line
killed the noise completely.
The resister itself was sufficient to rework existing systems. It
actually increased efficiency from 70% to 75%. The revised layout got
efficiency up to 80%.
>I still suggest getting an experienced engineer, versed in the black
>arts of EMC, etc. to help.
You need good equipment for this. I used to have a TEMPEST lab where
I used to work. It was nice to be able to grab a board and take it to
their 1 GHZ scope. You saw all kinds of things a regular 100mHz scope
hardly showed.
I miss having access to the TEMPEST gear. ;)
<Scott>
------
| Scott G. Henion| shenion@shen... |
| Consultant | Stone Mountain, GA |
| SHDesigns | PGP Key 0xE98DDC48 |
| http://www.shdesigns.org |
------
today's fortune
Your fly might be open (but don't check it just now). --
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.7/112 - Release Date: 9/26/2005
>I believe the switcher to be less likely as the cause of noise at
>151MHz.
That is not what I have seen. Although most I have seen with problems
were in the 20-30mHz range.
> Properly designed and laid out switching power supplies
>should have toroids (containing more of the field) and proper
>capacitance.
Toroids help with magnetic fields. For these small designs with a
sufficient ground plane, the surface-mount coils work well.
> The FET and control/switching circuits should be clamped
>for the inductive back voltage. Each device should be bypassed
>correctly, per applications information for the part or from
>experience.
I have seen HF noise on switching designs I have had to fix these
problems on. One of them was 24v/5A that ran at 20kHZ. That
broadacast a huge signal at about 27 mHz and also at 65mHz.
65MHz was the resonant frequency of the coil and stray capacitance.
There was no snubber to prevent this oscillation.
27MHz was the big problem, someone decided to move the MOSFETs to the
opposite side of the heatsink to improve assembly. This increased the
gate/drain length. The inductance of the leads caused the MOSFET to
oscillate at 27mHz at turn on. A 3 amp 27mHz signal radiated quite
well ;). Increasing the trace width drastically helped (freq went to
33mHz but was far less oscillation.) Increasing the gate drive
capability and then adding a very small resistor to the gate line
killed the noise completely.
The resister itself was sufficient to rework existing systems. It
actually increased efficiency from 70% to 75%. The revised layout got
efficiency up to 80%.
>I still suggest getting an experienced engineer, versed in the black
>arts of EMC, etc. to help.
You need good equipment for this. I used to have a TEMPEST lab where
I used to work. It was nice to be able to grab a board and take it to
their 1 GHZ scope. You saw all kinds of things a regular 100mHz scope
hardly showed.
I miss having access to the TEMPEST gear. ;)
<Scott>
------
| Scott G. Henion| shenion@shen... |
| Consultant | Stone Mountain, GA |
| SHDesigns | PGP Key 0xE98DDC48 |
| http://www.shdesigns.org |
------
today's fortune
Your fly might be open (but don't check it just now). --
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.7/112 - Release Date: 9/26/2005
Reply by ●September 27, 20052005-09-27
You mention 151.0688MHz. What is the
significance/relationship between this frequency and
the radio(s) being interfered with?
kevin
--- Mike van Meeteren <mike@mike...> wrote:
> Guys,
>
> I'm having a problem with our RCM3000 equipped
> product generating RFI
> interference. Our product is a piece of electronics
> that is installed in
> DOT style snow removal equipment, and it interferes
> with their business
> band two way radios when they use frequencies close
> to the RFI generated by
> the Rabbit core.
>
> We had a radio guy work with our equipment and
> determined with a frequency
> counter that the biggest signal was at 151.0688 MHz.
> Our entire
> electronics package is enclosed in a grounded die
> cast aluminum case, with
> several connectors to the outside of the box
> (including the ethernet jack
> on the core). From previous testing it appears to
> be bleeding out over a
> 9600 baud serial cable, which seems odd. I assume
> that the signal must be
> seeping out over the ground plane. The only thing
> that runs at anything
> close to that frequency is the clock on the Rabbit
> Core. Most of the other
> stuff is in the KHz range.
>
> We're going to try to use some clamp on ferrite
> beads to solve the problem,
> but I'd like to hear if anyone else has had problems
> with this type of
> noise, and what they did to solve the problem.
>
> Thanks in advance!
>
> -Mike
__________________________________________________
significance/relationship between this frequency and
the radio(s) being interfered with?
kevin
--- Mike van Meeteren <mike@mike...> wrote:
> Guys,
>
> I'm having a problem with our RCM3000 equipped
> product generating RFI
> interference. Our product is a piece of electronics
> that is installed in
> DOT style snow removal equipment, and it interferes
> with their business
> band two way radios when they use frequencies close
> to the RFI generated by
> the Rabbit core.
>
> We had a radio guy work with our equipment and
> determined with a frequency
> counter that the biggest signal was at 151.0688 MHz.
> Our entire
> electronics package is enclosed in a grounded die
> cast aluminum case, with
> several connectors to the outside of the box
> (including the ethernet jack
> on the core). From previous testing it appears to
> be bleeding out over a
> 9600 baud serial cable, which seems odd. I assume
> that the signal must be
> seeping out over the ground plane. The only thing
> that runs at anything
> close to that frequency is the clock on the Rabbit
> Core. Most of the other
> stuff is in the KHz range.
>
> We're going to try to use some clamp on ferrite
> beads to solve the problem,
> but I'd like to hear if anyone else has had problems
> with this type of
> noise, and what they did to solve the problem.
>
> Thanks in advance!
>
> -Mike
__________________________________________________
Reply by ●September 27, 20052005-09-27
At 11:41 AM 9/27/2005 -0700, you wrote:
>
>You mention 151.0688MHz. What is the
>significance/relationship between this frequency and
>the radio(s) being interfered with?
They are close enough that our electronics is causing the radio to come out
of squelch. It thinks it's always receiving a signal, and therefore the
speaker is always playing "noise". Most of these radios have some sort of
non-adjustable auto noise floor. The ones that do have a manual squelch
have to be cranked up so far that the effective range of the radio is about
a mile. That and the received signal is noisy instead of clean.
--
Mike vanMeeteren fast351@fast... FASTechnologies Corp.
Track Hauler: 2001 F150 Track toy: 89 Mustang LX 351W 10.93 @ 122.5 MPH
>
>You mention 151.0688MHz. What is the
>significance/relationship between this frequency and
>the radio(s) being interfered with?
They are close enough that our electronics is causing the radio to come out
of squelch. It thinks it's always receiving a signal, and therefore the
speaker is always playing "noise". Most of these radios have some sort of
non-adjustable auto noise floor. The ones that do have a manual squelch
have to be cranked up so far that the effective range of the radio is about
a mile. That and the received signal is noisy instead of clean.
--
Mike vanMeeteren fast351@fast... FASTechnologies Corp.
Track Hauler: 2001 F150 Track toy: 89 Mustang LX 351W 10.93 @ 122.5 MPH
Reply by ●September 28, 20052005-09-28
Harmonics of a source can cause a radio to break squelch.
Start dividing the radio freq down to determine if you have a
component source that can cause the harmonic.
9.875Mhz, 19.75, 39.5, 79, 158. (by two)
jmtcw:
Don Lewis --- In rabbit-semi@rabb..., Mike van Meeteren <mike@f...> wrote:
> At 11:41 AM 9/27/2005 -0700, you wrote:
> >
> >You mention 151.0688MHz. What is the
> >significance/relationship between this frequency and
> >the radio(s) being interfered with?
>
> They are close enough that our electronics is causing the radio to
come out
> of squelch. It thinks it's always receiving a signal, and therefore
the
> speaker is always playing "noise". Most of these radios have some
sort of
> non-adjustable auto noise floor. The ones that do have a manual
squelch
> have to be cranked up so far that the effective range of the radio
is about
> a mile. That and the received signal is noisy instead of clean.
>
> --
> Mike vanMeeteren fast351@f... FASTechnologies Corp.
> Track Hauler: 2001 F150 Track toy: 89 Mustang LX 351W 10.93 @
122.5 MPH
Start dividing the radio freq down to determine if you have a
component source that can cause the harmonic.
9.875Mhz, 19.75, 39.5, 79, 158. (by two)
jmtcw:
Don Lewis --- In rabbit-semi@rabb..., Mike van Meeteren <mike@f...> wrote:
> At 11:41 AM 9/27/2005 -0700, you wrote:
> >
> >You mention 151.0688MHz. What is the
> >significance/relationship between this frequency and
> >the radio(s) being interfered with?
>
> They are close enough that our electronics is causing the radio to
come out
> of squelch. It thinks it's always receiving a signal, and therefore
the
> speaker is always playing "noise". Most of these radios have some
sort of
> non-adjustable auto noise floor. The ones that do have a manual
squelch
> have to be cranked up so far that the effective range of the radio
is about
> a mile. That and the received signal is noisy instead of clean.
>
> --
> Mike vanMeeteren fast351@f... FASTechnologies Corp.
> Track Hauler: 2001 F150 Track toy: 89 Mustang LX 351W 10.93 @
122.5 MPH
Reply by ●October 6, 20052005-10-06
Guys,
I've narrowed down the problem with our device to the RabbitCore. I also
can't seem to get rid of the problem. The core generates radio noise even
with only power and ground connected. I am pursuing two different
approaches now, one deals with shielding the RCM3000, the other deals with
using an RCM3200 with a 44 MHz clock instead of a 29 MHz clock, moving the
interference frequency out of the range of the two way radio our customers use.
I have never worked with an RCM3200 before, and everything seems to be
going smoothly so far. I have run across a couple small issues I would
like some help from you guys to resolve:
RCM3200 specific questions:
Do you HAVE to run "Compile to flash, run in RAM"?
I am getting the following error if I compile to flash:
line 1 : WARNING DKENTRY.LIB : Origin xmemcod2 collides with origin
rootdata starting at physical address 0xf8000.
line 1 : WARNING DKENTRY.LIB : Origin xmemcod2 collides with origin
watcode starting at physical address 0xfdc00.
And the following errors if I compile to flash run in ram:
line 822 : WARNING Rabbitbios.c : USE_2NDFLASH_CODE disabled when
compiling to RAM.
line 823 : ERROR Rabbitbios.c : Comment out this #error to compile with
disabled USE_2NDFLASH_CODE.
(Do I not need to use "USE_2NDFLASH_CODE" to compile a >256K program to a
3200?)
The BBRAM option seems to not work running from FLASH.
The documentation about running in RAM is lousy. Pretty dissappointed with
that.
-Mike
I've narrowed down the problem with our device to the RabbitCore. I also
can't seem to get rid of the problem. The core generates radio noise even
with only power and ground connected. I am pursuing two different
approaches now, one deals with shielding the RCM3000, the other deals with
using an RCM3200 with a 44 MHz clock instead of a 29 MHz clock, moving the
interference frequency out of the range of the two way radio our customers use.
I have never worked with an RCM3200 before, and everything seems to be
going smoothly so far. I have run across a couple small issues I would
like some help from you guys to resolve:
RCM3200 specific questions:
Do you HAVE to run "Compile to flash, run in RAM"?
I am getting the following error if I compile to flash:
line 1 : WARNING DKENTRY.LIB : Origin xmemcod2 collides with origin
rootdata starting at physical address 0xf8000.
line 1 : WARNING DKENTRY.LIB : Origin xmemcod2 collides with origin
watcode starting at physical address 0xfdc00.
And the following errors if I compile to flash run in ram:
line 822 : WARNING Rabbitbios.c : USE_2NDFLASH_CODE disabled when
compiling to RAM.
line 823 : ERROR Rabbitbios.c : Comment out this #error to compile with
disabled USE_2NDFLASH_CODE.
(Do I not need to use "USE_2NDFLASH_CODE" to compile a >256K program to a
3200?)
The BBRAM option seems to not work running from FLASH.
The documentation about running in RAM is lousy. Pretty dissappointed with
that.
-Mike
Reply by ●October 6, 20052005-10-06
At 11:45 AM 10/6/2005, you wrote:
>Guys,
>
>I've narrowed down the problem with our device to the RabbitCore. I also
>can't seem to get rid of the problem. The core generates radio noise even
>with only power and ground connected. I am pursuing two different
>approaches now, one deals with shielding the RCM3000, the other deals with
>using an RCM3200 with a 44 MHz clock instead of a 29 MHz clock, moving the
>interference frequency out of the range of the two way radio our
>customers use.
>
>I have never worked with an RCM3200 before, and everything seems to be
>going smoothly so far. I have run across a couple small issues I would
>like some help from you guys to resolve:
>
>RCM3200 specific questions:
>
>Do you HAVE to run "Compile to flash, run in RAM"?
>I am getting the following error if I compile to flash:
>
>line 1 : WARNING DKENTRY.LIB : Origin xmemcod2 collides with origin
>rootdata starting at physical address 0xf8000.
>line 1 : WARNING DKENTRY.LIB : Origin xmemcod2 collides with origin
>watcode starting at physical address 0xfdc00.
I have seen that. Usually exit DC and recompile bios helps. This
seems normal buggy compiler stuff.
>And the following errors if I compile to flash run in ram:
>
>line 822 : WARNING Rabbitbios.c : USE_2NDFLASH_CODE disabled when
>compiling to RAM.
>line 823 : ERROR Rabbitbios.c : Comment out this #error to compile with
>disabled USE_2NDFLASH_CODE.
>
>(Do I not need to use "USE_2NDFLASH_CODE" to compile a >256K program to a
>3200?)
No, the RCM3200 has one flash chip for 512k. The other modules have
two, 256k chips and need the define (normally the second flash is
reserved for a file system.)
>The BBRAM option seems to not work running from FLASH.
It only works in the compile to flash, run in RAM mode.
>The documentation about running in RAM is lousy. Pretty dissappointed with
>that.
Yes, it is almost nil. The memory map is also not documented. Then
again, it changes in almost every version of DC so documenting it
would be a pain.
<Scott>
------------
| Scott G. Henion | shenion@shen... |
| Consultant | SHDesigns |
------------
Rabbit Libs: http://www.shdesigns.org/rabbit/
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.11/121 - Release Date: 10/6/2005
>Guys,
>
>I've narrowed down the problem with our device to the RabbitCore. I also
>can't seem to get rid of the problem. The core generates radio noise even
>with only power and ground connected. I am pursuing two different
>approaches now, one deals with shielding the RCM3000, the other deals with
>using an RCM3200 with a 44 MHz clock instead of a 29 MHz clock, moving the
>interference frequency out of the range of the two way radio our
>customers use.
>
>I have never worked with an RCM3200 before, and everything seems to be
>going smoothly so far. I have run across a couple small issues I would
>like some help from you guys to resolve:
>
>RCM3200 specific questions:
>
>Do you HAVE to run "Compile to flash, run in RAM"?
>I am getting the following error if I compile to flash:
>
>line 1 : WARNING DKENTRY.LIB : Origin xmemcod2 collides with origin
>rootdata starting at physical address 0xf8000.
>line 1 : WARNING DKENTRY.LIB : Origin xmemcod2 collides with origin
>watcode starting at physical address 0xfdc00.
I have seen that. Usually exit DC and recompile bios helps. This
seems normal buggy compiler stuff.
>And the following errors if I compile to flash run in ram:
>
>line 822 : WARNING Rabbitbios.c : USE_2NDFLASH_CODE disabled when
>compiling to RAM.
>line 823 : ERROR Rabbitbios.c : Comment out this #error to compile with
>disabled USE_2NDFLASH_CODE.
>
>(Do I not need to use "USE_2NDFLASH_CODE" to compile a >256K program to a
>3200?)
No, the RCM3200 has one flash chip for 512k. The other modules have
two, 256k chips and need the define (normally the second flash is
reserved for a file system.)
>The BBRAM option seems to not work running from FLASH.
It only works in the compile to flash, run in RAM mode.
>The documentation about running in RAM is lousy. Pretty dissappointed with
>that.
Yes, it is almost nil. The memory map is also not documented. Then
again, it changes in almost every version of DC so documenting it
would be a pain.
<Scott>
------------
| Scott G. Henion | shenion@shen... |
| Consultant | SHDesigns |
------------
Rabbit Libs: http://www.shdesigns.org/rabbit/
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.11/121 - Release Date: 10/6/2005
Reply by ●October 6, 20052005-10-06
Mike,
First about the noise. Did you try the different settings of the
Rabbit 3000 clock spreader. It might help.
The RCM3200:
- You can compile to Flash, but then you will have 1 waitstate, thus
slowing down the 'fast' 44MHz cpu.
- You should use the 'Compile to Flash, run in RAM' option. The DC
BIOS first copies the complete Flash contents to a fast-SRAM chip on
the RCM3200 module, then restarts the program from SRAM. Result: 0
waitstate operation.
Try this with a RABBITBIOS.C file on which you did not make any manual
changes. The errors you get (USE_2NDFLASH_CODE) are there because you
made some changes to the BIOS, not applicable for the RCM3200.
The RCM3200 has the full 512kByte available for program, without tricks.
Now, about the memory map of the RCM3200, it's a bit complicated.
Mode 1: Compile to RAM
- Maps the 256kByte ss-ram to all 4 quadrants
- 1 waitstate operation
- code, data, everything shares the 256kByte bb-sram
I dont know why you should use this mode. Maybe during development to
save the Flash?
Mode 2: Compile to Flash
- Maps 512kByte Flash to Q0 and Q1 = 512kByte program memory with 1
waitstate
- Maps 512kByte of Fast-SRAM to Q2 and Q3 = 512kByte of data memory
with 0 waitstate
Mode 3: Compile to Flash, run in RAM
- Maps 512kByte of Fast-SRAM to Q0 and Q1 = 512kByte program memory
with 0 waitstate
- Maps 256kbyte of bb-sram to Q2 = 256kByte of data memory
- Maps top 256kByte of Flash to Q3 = to have direct access to the User
block.
DC plays tricks with this third mode.
1. It maps root data always in the Fast-SRAM. Practically this reduces
the total amount of available program memory in this mode by about
30-56kByte. Your advantage: 0 waitstate root data access.
2. It uses all unused Fast-SRAM for xmem data memory (xalloc things).
Say you have a 300kByte program, the remaining 200kByte is available
for xallocs.
Only when all the Fast-SRAM is used, xalloc uses the 256kByte bb-sram.
You can overwrite this mode, have a look at the xalloc() function
description.
3. A 4kbyte root window is opened to have root access to the bb-sram.
This can be used with the bbram keyword. Any data stored in here can
be kept in memory during power off (if a battery is installed).
Unless you need the complete 512kByte program memory, mode 3 is the
fastest and best mode to use on the RCM3200. Mind you that also in
Flash mode you loose about 32kByte for the IDBlock.
Last thing, the root memory map on mode 3 (default BIOS setting):
0x0000->0xBFFF: root code and data (depends on bios setting and I&D)
and interrupt vectors, and watchtables, etc...
0xC000->0xCFFF: window to bb-sram
0xD000->0xDFFF: stack window
0xE000->0xFFFF: xmem window
Only 4 windows available on the Rabbit, that's it.
Hope it helps you understanding the RCM3200.
Rudi
www.x-graph.be the next generation Rabbit SBC with (Color TFT) LCD
First about the noise. Did you try the different settings of the
Rabbit 3000 clock spreader. It might help.
The RCM3200:
- You can compile to Flash, but then you will have 1 waitstate, thus
slowing down the 'fast' 44MHz cpu.
- You should use the 'Compile to Flash, run in RAM' option. The DC
BIOS first copies the complete Flash contents to a fast-SRAM chip on
the RCM3200 module, then restarts the program from SRAM. Result: 0
waitstate operation.
Try this with a RABBITBIOS.C file on which you did not make any manual
changes. The errors you get (USE_2NDFLASH_CODE) are there because you
made some changes to the BIOS, not applicable for the RCM3200.
The RCM3200 has the full 512kByte available for program, without tricks.
Now, about the memory map of the RCM3200, it's a bit complicated.
Mode 1: Compile to RAM
- Maps the 256kByte ss-ram to all 4 quadrants
- 1 waitstate operation
- code, data, everything shares the 256kByte bb-sram
I dont know why you should use this mode. Maybe during development to
save the Flash?
Mode 2: Compile to Flash
- Maps 512kByte Flash to Q0 and Q1 = 512kByte program memory with 1
waitstate
- Maps 512kByte of Fast-SRAM to Q2 and Q3 = 512kByte of data memory
with 0 waitstate
Mode 3: Compile to Flash, run in RAM
- Maps 512kByte of Fast-SRAM to Q0 and Q1 = 512kByte program memory
with 0 waitstate
- Maps 256kbyte of bb-sram to Q2 = 256kByte of data memory
- Maps top 256kByte of Flash to Q3 = to have direct access to the User
block.
DC plays tricks with this third mode.
1. It maps root data always in the Fast-SRAM. Practically this reduces
the total amount of available program memory in this mode by about
30-56kByte. Your advantage: 0 waitstate root data access.
2. It uses all unused Fast-SRAM for xmem data memory (xalloc things).
Say you have a 300kByte program, the remaining 200kByte is available
for xallocs.
Only when all the Fast-SRAM is used, xalloc uses the 256kByte bb-sram.
You can overwrite this mode, have a look at the xalloc() function
description.
3. A 4kbyte root window is opened to have root access to the bb-sram.
This can be used with the bbram keyword. Any data stored in here can
be kept in memory during power off (if a battery is installed).
Unless you need the complete 512kByte program memory, mode 3 is the
fastest and best mode to use on the RCM3200. Mind you that also in
Flash mode you loose about 32kByte for the IDBlock.
Last thing, the root memory map on mode 3 (default BIOS setting):
0x0000->0xBFFF: root code and data (depends on bios setting and I&D)
and interrupt vectors, and watchtables, etc...
0xC000->0xCFFF: window to bb-sram
0xD000->0xDFFF: stack window
0xE000->0xFFFF: xmem window
Only 4 windows available on the Rabbit, that's it.
Hope it helps you understanding the RCM3200.
Rudi
www.x-graph.be the next generation Rabbit SBC with (Color TFT) LCD
