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
RCM3000 hardware problems
Started by ●December 28, 2015
Reply by ●December 28, 20152015-12-28
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, k...@shail.co.uk [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
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, k...@shail.co.uk [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
Reply by ●December 29, 20152015-12-29
Ken,
Years ago we had a similar problem where the module would boot up with incorrect baud rates. As Tom suggested, we modified our initialization code to set the clock divisors an not rely on the Bios to do it. That solved the problem for us.
Steve
Sent from my Galaxy Tab® S2-------- Original message --------From: "k...@shail.co.uk [rabbit-semi]" Date: 12/28/2015 8:18 AM (GMT-08:00) To: r... Subject: [rabbit-semi] RCM3000 hardware problems
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
Years ago we had a similar problem where the module would boot up with incorrect baud rates. As Tom suggested, we modified our initialization code to set the clock divisors an not rely on the Bios to do it. That solved the problem for us.
Steve
Sent from my Galaxy Tab® S2-------- Original message --------From: "k...@shail.co.uk [rabbit-semi]" Date: 12/28/2015 8:18 AM (GMT-08:00) To: r... Subject: [rabbit-semi] RCM3000 hardware problems
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
Reply by ●December 29, 20152015-12-29
Ken,
I also ran into this. We had the wrong cap on the crystal and it did not start up at the right frequency but eventually locked in. Putting the correct cap on solved the problem. Since then I used an oscillator, now I don’t have to worry about purchasing buying a different manufacturers crystal that wants 22pf instead of 18pf.
-Pete F
From: r... [mailto:r...]
Sent: Tuesday, December 29, 2015 11:59 AM
To: r...
Subject: RE: [rabbit-semi] RCM3000 hardware problems
Ken,
Years ago we had a similar problem where the module would boot up with incorrect baud rates. As Tom suggested, we modified our initialization code to set the clock divisors an not rely on the Bios to do it. That solved the problem for us.
Steve
Sent from my Galaxy Tab® S2
-------- Original message --------
From: "k...@shail.co.uk [rabbit-semi]" >
Date: 12/28/2015 8:18 AM (GMT-08:00)
To: r...
Subject: [rabbit-semi] RCM3000 hardware problems
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
I also ran into this. We had the wrong cap on the crystal and it did not start up at the right frequency but eventually locked in. Putting the correct cap on solved the problem. Since then I used an oscillator, now I don’t have to worry about purchasing buying a different manufacturers crystal that wants 22pf instead of 18pf.
-Pete F
From: r... [mailto:r...]
Sent: Tuesday, December 29, 2015 11:59 AM
To: r...
Subject: RE: [rabbit-semi] RCM3000 hardware problems
Ken,
Years ago we had a similar problem where the module would boot up with incorrect baud rates. As Tom suggested, we modified our initialization code to set the clock divisors an not rely on the Bios to do it. That solved the problem for us.
Steve
Sent from my Galaxy Tab® S2
-------- Original message --------
From: "k...@shail.co.uk [rabbit-semi]" >
Date: 12/28/2015 8:18 AM (GMT-08:00)
To: r...
Subject: [rabbit-semi] RCM3000 hardware problems
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
Reply by ●January 19, 20162016-01-19
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: r... [mailto:r...]
Sent: December-28-15 1:19 PM
To: r...
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, k...@shail.co.uk
[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
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: r... [mailto:r...]
Sent: December-28-15 1:19 PM
To: r...
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, k...@shail.co.uk
[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
Reply by ●January 20, 20162016-01-20
Problems like this are often an indication of a grounding issue. The
programming cable provides a ground connection back to your computer. Make sure
your RS485 connections are set up correctly -- this page seems to imply that
devices should share a common ground in addition to the differential voltage
pair:
http://www.chipkin.com/rs485-cables-why-you-need-3-wires-for-2-two-wire-rs485/
-Tom
On Jan 19, 2016, at 3:53 PM, 'Yang Hong' y...@omniverter.com [rabbit-semi] wrote:
> 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?
-Tom
On Jan 19, 2016, at 3:53 PM, 'Yang Hong' y...@omniverter.com [rabbit-semi] wrote:
> 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?
