Forums

Rabbit 6000 I/O Bank Extended Register Issue

Started by granfaloon 2 weeks ago10 replieslatest reply 2 days ago30 views

Hello, I'm working on a project with the Rabbit RCM6750 MiniCore module which runs on the Rabbit 6000 CPU. According to the Rabbit 6000 CPU User's Manual from Digi.com, on page 358 it lists information for accessing and writing to the I/O Bank Extended Register. It is indexed as IBxER where the x corresponds to the I/O bank you'd like to write to 0-7. However when I use the insruction WrPortI(IB0ER, NULL, value); in Dynamic C I get the compiler error: IB0ER is out of scope/ not declared. Why is this? Is this register not available? If not, why include it in the cpu user's manual? 

[ - ]
Reply by CustomSargeSeptember 6, 2019

Sounds like a library file not being included, therefore register names aren't defined.

[ - ]
Reply by granfaloonSeptember 6, 2019

Thanks for the reply. I thought this as well, however all other register names seem to be defined and are addressable according to the datasheet. IBxER appears to not be defined for some reason.

[ - ]
Reply by mr_banditSeptember 10, 2019
TRy defining it and using it. Nothing to lose...
[ - ]
Reply by mr_banditSeptember 13, 2019

How's it going? Figured it out?

[ - ]
Reply by granfaloonSeptember 13, 2019

Thanks, for the reply. I tried defining and using it like this:


#define IB0ER 0x0451  // Address according to page 358 of Rabbit 6000 datasheet

WrPortI(IB0ER, NULL, 0);


This doesn't produce a compilation error, however it doesn't seem to affect this memory location's value.

[ - ]
Reply by mr_banditSeptember 13, 2019

What does it read before the write, and why/what are you trying to do?

This sets the databus size and speed. What do you need instead of the default?

[ - ]
Reply by granfaloonSeptember 18, 2019

I'm working on a project for work that interfaces a Rabbit 6000 to an FPGA. The fpga implements a 512byte FIFO and an SPI interface to an A/D converter. The Rabbit 6000 is tasked with handling the data transactions to and from the FPGA. To do this the Rabbit is connected to the FPGA using the Rabbit's external I/O bus. Sometimes, on polling the fifo done flags and reading out the fifo data, the reads from the fpga to the rabbit fail. I've tried reducing the default amount of wait states from 15 to 1 and 3 but this doesn't seem to help. Looking at the datasheet I tried to configure the IB0ER register and came accross the issues i outlined in this post. I was thinking maybe, the I/O transactions were happing to quickly so according to the datasheet it should be possible to reduce bus transaction speed by configuring the IB0ER.

[ - ]
Reply by mr_banditSeptember 18, 2019

Seems like you are not sure of which side is causing the issue.

First, I would suggest bit-banging the SPI at a low rate. This will tell you if the FPGA has a basic SPI issue. Then increase to as fast as you can bit-bang it (which is still slower than the peripheral), just to see if that makes a difference (should not matter).

Since this is your FPGA, you can also introduce delays as needed for testing. You might have an internal race condition (a SWAG).

Another thing you can do is get an Arduino Mega and make it a SPI slave to the Rabbit master. This can tell you if there is an issue with the Rabbit. And - make the Mega the SPI master to the FPGA slave. That may tell you the FPGA fails with another master.

Short version: you need to find out which side the issue is on, assuming only one side is misbehaving.

Also - have you looked at doing an ISR on the rabbit side? Why are you polling (although that should work...)

[ - ]
Reply by granfaloonSeptember 18, 2019

All good suggestions, however I won't be able to use another device to investigate as the board is already designed and all the components are in place. I think the issue is on the fpga side as all other reads to the fpga's internal registers work fine and are consistent. Only the reads to the fifo registers fail.


What is the internal race condition?

[ - ]
Reply by mr_banditSeptember 18, 2019

You could get a Rabbit board (same model & clock) and run your code on it. You could also get an eval board with the same FPGA and use it for the experiments.

You *might* have some race condition in the FPGA. The reads to the FPGA FIFO register failing is a pretty obvious clue something is wrong on the FPGA side. I am assuming the PCB does not have something like a bad solder joint.

DO you only have one board? If more than one, is the behavour the same or different between the boards?