problem using the programming cable!!

Rabbit
1

Dear All,

 I wish that you can help me. Briefly I'am an RCM4110 user and when I

loaded my program and I passed to the execution mode I can’t get out from

it . when I compile my program with (PROG) I get always Can’t send the cold boot: No rabbit microprocessor detected!!. I tried to uninstall and reinstall the dynamic C,I used another RCM (RCM4100),I use for communications and compiler tabs default values, but the problem does persist…Give me a solution please I’m doing a project of final studies.

Many thanks.

2

I’m afraid to say there is no solution for this.
I too have seen this problem many times.

What has happened is that the RCM has gone bad. Try returning it to your supplier.

3

This may or may not be due to a dead core module. There are several simple problems that can cause this same error. Make sure your PROG connector is attached correctly, red stripe at the side of the connector that have the little 1 2 markings. Make sure that your core module is properly plugged into the development board. It is very easy to insert the core with pins hanging off one side or the other of the core module socket. Do a visual inspection after inserting the core. Not putting power to the development board. Check that you have selected the proper serial port within Dynamic C. Simple items, but any one of these issues will stop your programming session dead in their tracks.

If you are finding that you are losing core modules frequently, you should look at your anti-static precautions. Understand that these are embedded modules, and as such, do not have the typical outer protection. We have components to help protect the circuitry on normally exposed connectors such as the ethernet jack, but you can zap a core module at many places that do not have much static protection. If you are experiencing frequent module failures, most likely you need to improve your anti-static handling techniques.

4

Bill,

Thanks for the response.
I have to say in defense, and I can only speak for myself, that my anti-static precautions are second to none. I also fully understand the nature of the failure on my modules.

With the programming cable connected, the SMODE pins are held high. This causes the rabbit processor to enter the cold boot, via ASYNCH Serial on Port A, at 2400 Baud. Then instructions are sent to the processor as triplets - MSB, LSB of address, followed by value. If the Highest bit of the MSB is set then the address is interpreted as an internal register address.

When I scope out the serial port, the reset and SMODE and STATUS lines I can see DC trying to toggle the STATUS line, but the status line does not respond.

This means that either the status line has gone bad, or the processor has not entered the hardware boot loader. I doubt very much that it is the status line going bad, since if you skip the processor verification it still does not work, and the status line is only used by the processor verification.

Now, the firmware which is still on board from previous successful programming cycles still runs perfectly, and (in my case) as it happens contains a full hardware test routine.

Every single parallel port, and serial port on the device is working perfectly.
(Including serial port A)

If the problem was caused by ESD damage, what are the chances that each module would die in exactly the same way? That must be millions to one against.

My own guess is that somehow the clock for serial port a is changed and the boot loader does not recognize the triplets being sent at 2400 - or serial port A can not be initialized by some other problem.

Following on, if you disable processor verification in DC, it will skip the toggling of the status line, and go straight to loading the initial loader - basically it’s working blind at that point as there is no feedback from the processor until it jumps to 6000 and starts the new loader. That fails, therefore the triplets being sent are not working.

I definitely do not think this is an ESD issue. I think there is some set of instructions that can prevent the processor going into the boot loader, or prevent serial port A working properly in the boot loader.

In my case I suspect that the modules tend to die when a compile error occurs. I believe the programming process goes something like this… detect processor, load initial loader, get processor ID, Flash Configuration etc, compile libs and program, then send compiled program to the device.

I suspect that if a compile error occurs, then DC leaves the processor in some kind of state that cannot be recovered from. But this is pure speculation at this point.

So, in summary, I do not think it is ESD damage, as hardware test prove that everything still works. The programming cable still resets the device, still holds the SMODE lines high, and you can ignore the status line by unticking ‘enable processor verification’ - there’s nothing else to have been zapped!

-LHM

5

Hopefully you did not take my response as accusational, but this is an open forum and there were many items that a novice user may have overlooked. Your situation definitely seems unique. Most times, when we see large numbers of module failures, the most prominent cause is ESD handling. I have checked with tech support and we do not have an inablility to program problem being reported on a large scale. So this brings up the question of why are you seeing it?

Which core module are you having this issue with? Are you using our prototyping board, or a host board of your own design? Have you tried multiple programming cables? Have you brought this problem up with our tech support department? I would like to find the true culprit of this problem as you should not be able to get a core module in a state where it does not program unless you have damaged it in hardware.

6

Mr Sprouse

No - worries! I did not take your post as accusational!

Yeah, I’d love to get to the bottom of it too.
I’m in the uk and over the past few years I’ve bought, probably about 20 modules or so from your distributor 2001 Electronics.

I’ve had about 4 modules go bad in this way over the years. Two of them in the past 6 months. The two recent modules were both RCM4010, the others were a RCM2200 and a RCM2010.

I’m just about to return two to 2001 for them to investigate. (The two RCM4010 which are still under warranty).

I’d love to pin point the cause too, as it is expensive to replace them.

The boards are programmed on the dev kit board, then moved to a board of my own design. I don’t programme them on-board as my board uses all 5 available serial ports - including PORT A.

I’ve kinda hijacked the OPs thread here with my own issues - I’d be happy to discuss them off-board, and I’m totally open to all advice and criticism - any thing that will help!

-Kenny

7

I am having the same problem. I’ve programmed over 200+ units, started getting the problem intermittantly, now cant get anything to program at all… Its not a problem with the core modules, and i have two cables - niether work. help please!

8

I have found the problem - is the ribbon cable from the programming PCB to the unit. I buzzed it out and found pins 1 and 2 open circuit. I buzzed it when plugged into the programming PCB and the CPU, ie at the base of the 10 way header. It could be the connector wearing out ?? I have just bodged up a cable using the two leads i have, cutting both cables in two, and re-joining the ends which were plugged into the programming PCB’s and it works again…