We have manufactured a PCB based on R3000 keeping the RCM3700 as a reference. The board incorporates 512K Bytes Flash (39VF040), 256K Bytes RAM (IS62WV2568BLL), Crystal Oscillator 11.0592MHz, and 1MB Serial Flash (AT45DB081D), Crystal Oscillator of 32.768KHz, all the components related to the programming connector of the R3000, 3.3V Regulator IC and all the Decoupling Capacitors . The Board also has an Ethernet Interface but initially we have not assembled these things. All these things are similar to the RCM 3700 Board.
I have checked all the necessary Test Points for Voltage and Crystal Frequencies and seem to be OK. Connections of the Address Lines of R3000 and Flash and SRAM are also OK.
Also please note we have 9.62 Version of Dynamic C.
Now I want to run a simple code Demo1.c at DCRABBIT_9.62\Samples. I have done the setting as “Code and BIOS in RAM” since I want to check the interface between the R3000 and SRAM. While programming the board, I get a dialogue box of “Loading Initial Loader” and after few seconds,a different dialogue box appears saying “While Sending Pilot BIOS Target Communication Error”.
Please also note a point that, while programming through the RFU and the .bin file of Demo1.c, it gives a “Target Communication Error” while 873 bytes of 72565 bytes are being sent. It also displays “Error Reading Bytes”.
Could anybody can guide me to solve this problem?? Has anybody experienced this type of problem??
I suggest that you compare singnals from your pcb against those of the RCM3700 using a scope.
Concentrate on txa as the error would suggest there is an issue Reading bytes back from the device.
Please confirm me on this:
R3000 Board requires both the SRAM and Flash Memories on board to execute any simple program.
Because, I have observed that the /CS0 (/Chip Select 0) for the Flash does not toggle while programming the board where as the the /CS1 (/Chip Select 1) for the SRAM toggle that time. I compared this with the RCM3700 Board and observed that both these pins toggle while programming any small code.
Does the Pilot BIOS always get loaded in Flash though I set Code and BIOS in RAM?? Please comment on this??
guys, I’ve spent a lot of time recently working on the cold boot process, pilot BIOS etc at very low hardware level. Guess I am kind of pro now
Do not expect it will go smooth immediately, especially if you design your own hardware (not using RCM modules). Do not start from directly trying to load from Dynamic C. There is a long long way before that stage.
you need to read a few times the “How Dynamic C Cold Boots the Target System” document. It is THE starting point.
check how your essential pins are connected and routed from R3000 all the way to computer’s COM port. Those are: #RESET, STATUS, RXA, SMODEx on the chip. Compare to “rabbit programming cable schematic digaram” document.
very first and basic test you need to do is this:
STAGE 1
a) SMODEx must be tied to VDD, then pulse a #RESET line low for at least 50mS
b) when #reset line is LOW (active), the STATUS pin must go HIGH. Once reset is complete (#reset=1=idle) and assuming CPU is running, STATUS pin must go LOW and TXA line must be LOW (serial port A not initialized completely). Every time you activate #RESET (#reset=0), STATUS must go HIGH for a moment then go back to LOW. Measure this with scope at the CPU pins, not in the COM port cable! RS-232 levels are inverted and represented by levels as 0= +10v, 1= 10v.
If you do not have this match, then check your hardware (schematics, PCB, crystal etc) - very likely that your CPU is not running. RAM or FLASH are not involved at this stage!
STAGE 2
If you passed this above test, you can try the next one:
do not use Dynamic C at this stage ! use SerialIO.exe program found in “Diagnostics” sub-folder of you C installation. This program is the essential tool to debug at very low level. It is really basic and has ugly user interface, but Z-World do not support this software. I actually have written a better program with the same functionality and more, only because it is really painful to use SerialIO :). Anyway, you need some software that can work with COM port on the PC side. You need to do this:
open port at 2400 bps;
you can toggle DTR once, but it must be idle after this. (Rabbit must be reset once DTR goes to active state =0). Check with the scope if the #RESET pin on rabbit goes LOW once you activate the DTR line in SerialIO (or other software). This is to confirm that you routing from PC’s DTR line is reaching #RESET. Once you change the state of DTR, the DSR indicator in SerialIO must toggle accordingly. If not - check your hardware and connectioins as described above.
STAGE 3
if you passed stage2, try this:
while port still open, type inside “transmit” line of SerialIO this sequence:
80 09 51 80 09 54 80 0E 20
and click transmit button
If you rabbit CPU is running and it is really in bootstrap mode the STATUS pin must go LOW
This sequence will toggle STATUS pin to HIGH again:
80 09 51 80 09 54 80 0E 30
Only if you are successfull on all these tests, you can continue further…
p.s. corrected pin states, previously I mixed inverted states from COM port lines with logical states of pins.
Before I read these, I could able to run the PC Board. But I think these are very important and very basic instructions to be followed when you are working on bringing up the self designed Rabbit based Systems. Anybody should not overlook these before proceeding further.
