Reply by Mike van Meeteren●October 6, 20052005-10-06
At 09:41 PM 10/6/2005 +0000, you wrote: >
>Is it not possible to use an RF shielded box in your application? The
>noise may still be there, but at least it's not getting out. They
>sell gaskets for connectors and tops that you could even use a
>standard box and shield the openings where the RF energy could escape.
>
>Matthew
That is one thing I will be pursuing in the near future. We're probably
going to work with a local EMI lab to figure this thing out. I'll make
sure we report our findings.
Reply by Mike van Meeteren●October 6, 20052005-10-06
At 09:29 PM 10/6/2005 +0000, you wrote: >First about the noise. Did you try the different
settings of the
>Rabbit 3000 clock spreader. It might help.
Oh, and yes, I did try playing the spectrum spreader and the clock doubler.
The interesting thing is that the frequency is not a harmonic of the system
clock. I don't know what is going on there, and until I get a look at
everything going on with a good spectrum analyzer, I won't have a good idea
what's really happening.
Reply by Matthew P. Kelton●October 6, 20052005-10-06
Is it not possible to use an RF shielded box in your application? The
noise may still be there, but at least it's not getting out. They
sell gaskets for connectors and tops that you could even use a
standard box and shield the openings where the RF energy could escape.
Matthew
--- In rabbit-semi@rabb..., Mike van Meeteren <mike@f...> 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.
>
> 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 xgraph1●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
Reply by Scott Henion●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
Reply by Mike van Meeteren●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
Reply by Don Lewis●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
Reply by Mike van Meeteren●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.
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