RE: RCM3000 hardware problems

"'Yang Hong' [email protected] [rabbit-semi]" <[email protected]> Tue, 19 Jan 2016 18:53:18 -0500
Newsgroups gmane.comp.hardware.rabbit-semiconductor
Organization Omniverter Inc.
Message-ID <[email protected]>
Hello, 

 

I am using BL4S200 with Modbus slave. I have some issue with USB-Serial
(RS485) converter. As soon as I use debug port, I can easily and fast to
connect BL4S200 via USB-Serial (RS485) converter to my pc application,
however, when I download program into flash and remove programming cable
from program port, It looks difficult to get connection with the same
converter. Anybody has any clue?

 

Regards,

 

Yang Hong

 

From: [email protected] [mailto:[email protected]] 
Sent: December-28-15 1:19 PM
To: [email protected]
Subject: Re: [rabbit-semi] RCM3000 hardware problems

 

  

Ken,

 

Does your system require a quick startup?  I seem to recall that there's a
section of the startup BIOS code that waits for the processor to settle
before doing the timing required to calculate the baud rate dividers.
Perhaps adding a greater delay there would correct the problem?

 

Can you have the module dump the calculated dividers during the startup
process?  Another solution I seem to recall in the past was that people
would just hard-code the divider, bypassing the BIOS code that calculates it
on each startup.  Seeing the calculated result may help you confirm that the
problem is with that section of code, and not some other hardware/peripheral
startup issue.

 

-Tom





 

On Dec 28, 2015, at 8:18 AM, [email protected] <mailto:[email protected]>
[rabbit-semi] wrote:

  

 

Has anyone seen a problem on the RCM3000 core modules where they fail to
initialise properly at power-up?

We are seeing it on RCM3110 and RCM3200 at lower temperatures, around 15 to
20 Celsius.

The symptoms are that the timers A and B do not produce the required
frequency divisions. Baud rates are wrong.

The symptoms are always cured by taking  /reset_in low manually. That sort
of eliminates our code.

 

Despite the fact that we are buying large quantities of Rabbit modules from
Digi they are being particularly un-helpful about this problem. I am afraid
that they appear much less helpful than the old Rabbit people.

They have given advice such as "connect an external reset timer to /reset_in
"!!. 

After one department suggested that we send a couple of troublesome modules
back for them to investigate another department refused to take them because
"they are out of warranty".

 

We have spent many hours testing and trying to eliminate any source of the
problem that might be in our application and can find none. We are convinced
that it is a design or manufacturing problem in the product.

 

Due to Digi's hard-line and unwillingness to support their product we have
decided to eliminate Rabbit modules or any other Digi product from any short
list of components for any new projects.

 

K.Shail

Sparc Systems Ltd.

UK
image001.jpg (image/jpeg, 359 B) - not displayed
image002.jpg (image/jpeg, 332 B) - not displayed