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? 

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

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.

How's it going? Figured it out?

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.

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?

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.

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...)

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?

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?

This has been a journey for sure but I think I figured it out. Page 68 of the Rabbit 6000 manual has the relevant info. By default the MMU can only access internal I/O registers addressed from 0x00 - 0xFF. By setting Bit 7 of MMIDR (Memory Management Instruction/Data Register) to 1 allows accessess to addresses at 0x0100 and above. The IB0ER register in question is at address 0x0451. These sets of instructions allow me to slow down the external I/O bus transaction speed:

WrPortI(MMIDR, NULL, 0x80);  // Bit 7 = 1 allows access above 0x0100

WrPortI(0x0451, NULL, 0x05); // IB0ER at address 0x0451

I predict it took you 3 days to find this. (the rest of the time you were killing other alligators in the swamp.)

I have forehead shaped holes in walls all around the country for things like this. They always resolve to a bit in a register, or a character or line in a file, or a check-mark, or a switch.

And it always takes 3 days, because the Daemon Murphy has a 3-day attention span.

Glad you found it.

Please consider, in future projects, to get prototype/eval boards to develop with. Reduces the risk and makes it much easier to develop the low-level stuff.

It was extremely frustrating for sure, I appreciate the help. I'll be sure to pass along your suggestion for prototype boards to the hardware guys. They seem to think that everything will work perfectly first go around.

Make a foam sword (a boffer) from a pool noodle, duct tape, and a dowel or pvc pipe.

Next time you do a project, smite the HW guys about the head to "remind" them you want good development boards, with the hooks you need. && you want eval boards for development. Also works wonders in design review meetings....

google "boffer sword"  - also allows kids to beat on each other with minimal damage. Also good for couples to settle arguments :^)

http://www.thealmightyguru.com/Boffer/Boffer-Generic.html

http://www.thealmightyguru.com/Boffer/Boffer-Swords.html

https://www.instructables.com/id/How-to-make-a-safe-and-sturdy-Boffer-Sword/