I moved my active projects from 8.?? to 9.10 last year, as the benefits
looked like it was worth the effort. I haven't been convinced to go
through that ordeal again.

I am using 9.25 for several development / concept activites, and it is
working fine for me. But I haven't taken the time to move my older
code.

Judging from previous comments on this thread, I'd be surprised if you
find anyone happy with 9.40.

Warning - opinion follows: One of the quirky things of DC is that they
are trying to demo lots of different things on different platforms.
This seems like it is starting to get overwhelming for them. I use
their library files as starting points - many need to be fixed even to
do what they are intended to do with their demo board. I have
generally done some pretty extensive editing for my specific
(RCM3000/3100) hardware and application.

I don't get here often, but I find that many of the posts on this site
seem to be of this same general nature.It may not always be easy, but
it is the life we've chosen. I'm glad you're all here for the support!

Jon

FYI,

It appears that rabbit no longer "recommends" 9.40 as an upgrade..

They changed the download site so that 9.25 is now the "Current"
version and there is a link: "Dynamic C 9.40 available here for
customers using the OP7200 or RabbitSys software."

--- In r..., "nerdx86" wrote:
>
> How many of you are using 9.40?? I think I've found some major bugs
> in the memory setup defines and macros, and am wondering if anyone
> else has found simular?
>

There were significant changes in Dynamic C 9.30-9.41 versions, if
you would like to view the details of these changes and a list of
known issues you can do so at:
http://www.rabbitsemiconductor.com/downloads/_pages/DC940/index.shtml

If you are experiencing difficulties with Dynamic C 9.30, 9.40 or
9.41, we recommend that you use Dynamic C 9.25 instead. You can
download Dynamic C 9.25 from our website at:
http://www.rabbitsemiconductor.com/downloads/_pages/DC9/. There are
specific products that require Dynamic C 9.30 or newer. You can
view this list of these products through the link above.

We are currently working on the next revision of Dynamic C 9 that
will address many of the issues with the current release.

If you have any questions or concerns please contact your sales
representative or our Technical Support group at support:
support@supp....

We at Rabbit are committed to providing our customers with quality
products in a timely manner. Please note that this site is not
actively monitored by Rabbit. If you need assistance, we encourage
you to contact us directly.

Thank you,
Rebecca League
Rabbit Semiconductor, Inc

Scott, I work for the engineering side of the business (we're actually a
separate company now) so couldn't tell you whether the RCM's we receive
are the same as the US ones. I actually doubt the distribution guys
would know (it's probably a question only ZWorld could answer).

I don't really wish to weigh in on this thread other than to say we have
used 1000's of RCM's from the different RCM families (and the Z180 range
previous to RCM's) over the last 12(?) years and have generally had good
experiences with them. You may occasionally have problems but whinging
about them on a non-ZWorld forum isn't necessarily solve your problem.
Contact ZWorld and raise the issue with them. Perhaps get your
distributor to help esculate the problem, even call them if need be.

I also don't agree with always updating to the latest version. We stick
with the same DC version throughout a projects lifespan unless there is
a very good reason to change. You're just making extra work for yourself
otherwise...

Nathan

We had about a dozen 3110's that refused to get programmed for the first time! We sent all of them back to the local distributor here in India.

Regards,

Tausif I. Kazi.

At 09:20 PM 3/16/2006 +0000, you wrote:
>
>I myself have had 2 or 3 cores with repeating patterns in the second
>flash.. We have't seen any in quite a while (9 months+), but....
>
>Here's my original description of the problem that I sent to zworld..
>If it's the same as your issues, then it's pretty curious, eh?

Looks IDENTICAL to my findings. I've probably had a dozen cores in the
last two months with identical problems. And the pace appears to be
picking up. Same as you, they're failing in the field.

--
Mike vanMeeteren fast351@fast... FASTechnologies Corp.
Track Hauler: 2001 F150 Track toy: 89 Mustang LX 351W 10.93 @ 122.5 MPH

Hello,

I would advise to get a magnifier and thoroughly inspect flash chip
pins soldering. We had similar problems with a lot of RCM3110 that had
too little soldering paste applied at bottom side (not exactly the
same, but we are not digged too deep that time - resoldering of flash
helped immediately, problem was visible by naked eye). Same inspection
can be done on a Rabbit processor itself.

This problem may be caused by broken soldering joint on one or more of
address lines.

BR,
Yuri

I myself have had 2 or 3 cores with repeating patterns in the second
flash.. We have't seen any in quite a while (9 months+), but....

Here's my original description of the problem that I sent to zworld..
If it's the same as your issues, then it's pretty curious, eh?

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

I have several RCM3000's in the field, and they seem to be
working well. I have recently had an issue with a controller failing
to function at a customer location (after running at the site for
approx 1 month). I sent them a new RCM and the carrier board it
attaches to and it worked fine for a period of 6 hours before it too
failed. I then visited the site, and tried combinations of the RCM
and the carrier and determined that the RCM was what
had failed (they have now been running on a new RCM and the old
carrier for over 1 week). To avoid confusion, I'm going to call the
RCM that ran for a month RCM1 and the one that ran for 6 hours RCM2.
I attempted the load fresh software to RCM1 using DC9.01 and it failed
after downloading 128 bytes of the user program. I attempted to load
fresh software to RCM2 using
DC9.01 and it succeeded but locks up on a call to flash_writesector
(Writing to sector 1 of the second flash).
I called tech support and talked to Dave Terra, he sent me a
program that maps each flash to address 0x80000 and allows me to
download it. I did so, and I noticed a strange pattern in RCM1's
Flash 1 and RCM2's Flash 2.

RCM1 Flash 1:
080030 26 CC D3 3A C3 00 CB 7F 28 05 CD 2A 12 18 18 CB &:(br /> 080040 FF FD FD FD FD FD FD FF FF FD FD FF FD FD FD FD
080050 FD FD FD FF FF FF FD FD FD FF FD FD FD FD FF FD br /> 080060 C5 D5 E5 DD E5 FD E5 D9 C5 D5 E5 CD 2E 00 E1 D1 .
080070 C1 D9 FD E1 DD E1 E1 D1 C1 F1 ED 67 F1 08 F1 ED br />
0bff70 FF FF FF FF FF FF FF FF FF FF FF FF 04 00 00 0F
0bff80 FD FD FF FD FD FD FF FD FF FF FF FF FF FD FD FD br /> 0bff90 FD FD FD FD FD FD FD FF FF FF FF FD FD FD FD FD br /> 0bffa0 10 40 00 2D 00 01 00 00 00 80 00 37 00 01 01 00 @ - 7
The FD's do not belong where they are, and also appear to be where the
download is crashing.
Notice the offset's: 32 FD & FF's starting at 0x0###40 and 32 FD &
FF's starting at 0x0###80

RCM2 Flash 2:

081050 85 8E 02 00 00 00 05 00 00 20 00 00 00 00 00 00
081060 FF FD FD FD FD FD FD FD FD FD FD FF FF FF FF FF
081070 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
081080 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

082050 40 00 04 04 00 00 00 00 00 08 02 00 00 20 00 00 @
082060 FD FD FF FD FD FD FD FD FD FD FF FD FD FD FD FD br /> 082070 FD FD FD FD FD FD FD FD FD FD FD FD FD FD FD FD
082080 00 00 03 00 00 20 00 00 00 00 00 00 00 20 00 00
082090 00 00 00 00 00 20 00 00 00 00 00 00 00 20 00 00
0820a0 FD FD FD FD FD FD FD FD FD FD FD FD FD FD FD FD
0820b0 FD FD FD FD FD FD FD FD FD FD FD FD FD FD FD FD
0820c0 00 00 00 00 00 20 00 00 00 00 00 00 00 20 00 00
0820d0 00 00 00 00 00 20 00 00 00 00 00 00 00 20 00 00
0820e0 00 00 00 00 00 20 00 00 00 00 00 00 00 20 00 00
0820f0 00 00 00 00 00 20 00 00 00 00 00 00 00 20 00 00
082100 00 00 00 00 00 20 00 00 00 00 00 00 00 20 00 00
082110 00 00 00 00 00 20 00 00 00 00 00 00 00 20 00 00
082120 00 00 00 00 00 20 00 00 00 00 00 00 00 20 00 00
082130 00 00 00 00 00 20 00 00 00 00 00 00 00 20 00 00
082140 00 00 00 00 00 20 00 00 00 00 00 00 00 20 00 00
082150 00 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00
082160 FD FD FD FD FD FD FD FD FD FD FD FD FD FD FD FD
082170 FD FD FD FD FD FD FD FD FD FD FD FD FD FD FD FD
082180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
082190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0821a0 FD FD FD FD FD FD FD FD FD FD FD FD FD FD FD FD
0821b0 FD FD FD FD FD FD FD FD FD FD FD FD FD FD FD FD
0821c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

The FD's do not belong where they are, and also appear to be where the
download is crashing. This pattern of FD's and some FF's repeats
through out the flash... Notice the offset's: 32 FD & FF's starting at
0x0###60 and 32 FD & FF's starting at 0x0###a0, repeating every
0x000100 throughout the memory.

This pattern is not present in functioning units and is not present on
the alternate Flash on the bad units. Dave thought that the problem
was caused by an errant pointer in a flash_writesector function, but I
disagree that this could be the root cause. RCM1 will not take new
data for the flash 1, and I do not ever write to this memory. For
this to be caused by an errant pointer Op, I'd have to repeatably
write to flash 1, and not hit the code area (which is a large area of
the flash). We would know if this unit was rebooting on watchdogs,
etc because of corrupted code.

These both occured on Rev H (3000A) RCM's. Do you have any type of a
revision list that gives information why changes were made to the
RCM's? If sending the units back to your site would help, we'd be
happy to do so.. I can also send copies of the flashes, etc..

At 11:28 PM 3/15/2006 +0000, you wrote:
>
>Mike,
>
>We have just had a couple of Rabbits returned with what looks like a
>2nd Flash problem in our RCM3100 cores (We're in Australia).
>Our user data is stored in the 2nd flash and we find that this data
>cannot be written (or sometimes has partially written elements).
>
>What symptoms do you experience with your 2nd Flash failures?

The core fails to run, (runs fine from RAM), when I compare the good flash
image to the read one, it's always a group of bytes in a pattern repeating
through the entire flash that's corrupted.

http://www.fastec.com/dumpbad.txt

http://www.fastec.com/dumpgood.txt

(text compare the two, you'll see what I mean...)

>
>Also, you mentioned doing a Flash dump - how do you go about this?

void main()
{
#asm
ld a,FLASH_WSTATES | CS_FLASH
ioi ld (MB2CR),a

; uncomment next 2 lines if you have 2, 256k chips

and 0xfc
or 0x2
ioi ld (MB3CR),a
#endasm
printf("From debug menu, select Dump Physical memory\n");
printf("Dump physical memory from 0x80000\n");
printf("Select dump to file, and # bytes in .bin file.\n");
while (1) ;
}
Run in RAM, follow directions...

-Mike
--
Mike vanMeeteren fast351@fast... FASTechnologies Corp.
Track Hauler: 2001 F150 Track toy: 89 Mustang LX 351W 10.93 @ 122.5 MPH