Custom R4000 design

Hello, I have recently created a board based on the R4000 (not the module) and I have not been able to successfully program the flash through Dynamic C yet.

The main processor is the R4000, the SRAM is 256K CY62138FV30, the FLASH is 256K SST39LF040.

I am able to toggle the STATUS pin on the program port using the SerialIO utility talked about on this forum and in R4000 Designers Handbook. I was also able to toggle an LED onboard using this serial IO utility.

Using the Dynamic C development environment (version 10.40) I have set up the compiler options:
“Enable processor verification” is on, If the board is not powered I get “No Rabbit processor detected” which goes away once it is powered so I know it sees the chip.

“Detect attached target memory type” is enabled

29.4912Mhz Base clock frequency (measured to be accurate into chip and coming out of Pin 2 of R4000)

256KB ram
256KB flash

Macros: CLK_DBL=1;NUM_RAM_WAITST=1;NUM_FLASH_WAITST=2

If I try to compile to target, it will properly recognize the R4000 chip, I think it successfully loads the cold loader (initial loader), because the error occurs while it is attempting to load the Pilot bios.

The window shows “trying to load pilot bios” and it shows the path to the pilot bios file. Then at the bottom status bar it shows “Reading board info” and then ends back at the source code with a “communication error” in the status bar. No popup error windows.

My first question is where can I view all the compiler Macro options? Are the wait states necessary, or are things slowed down during programming automaticly?

Is my flash chip supported? It appears not to be mentioned in FLASHWR.lib. However it is accurately present in the base directory for DynamicC in the file flash.ini. How to tell which flash driver system is being used by the bios?

The reference design for the RCM4200 is what I based most of my design on with a few exceptions:
I did not include the Schmitt trigger on the 32Khz clock input. Is this necessary? I thought I read in the documentation that the R4000 has an internal schmitt on each clock input. (The RCM4200 does have the extra schmitt trigger on the 32khz clock but an empty non populated trigger on the 29Mhz clock)

I may not have enough decoupling capacitors near the R4000 yet.
Would that cause communication problems?

Should I connect Address line 18 (A18) to the active high Chip select 2 (CE2) of the SRAM chip? Or should it be tied high?

I don’t see any communication on the RX line of the programming connector. It begins low voltage and after the initial loader it does switch to a high voltage, I assume the loader initializes the serial port. But it then never replies to the PC, such as I have viewed on the RCM4200.

What exactly is the bios/dynamicC doing in the “Reading board info” step, and what is the reply from the chip? Is it on the RX serial port, or is it just a toggle on the STATUS pin perhaps?

I was able to get the second troubleshooting step loaded via the SerialIO utility. It pulses all of the address lines (and I think the D0) data line? (this leads me to believe that I was right in attaching A18 to the SRAM CE2.

Is there any other resources that fully explain the BIOS procedure better? And perhaps all of the compiler MACRO options? (I have read the designers handbook but it doesnt mention anything about this “Reading board info” step) My best guess is this step is where it verifies the size of RAM?

One strange thing I noticed is that I was able to get a little farther in the programming process by reducing the baud rate to the lowest settings. It didn’t use to get to the communication error before, I believe it failed on the initial loader step with higher baud settings.

Thank you for your time.

I think I need an IDblock in my flash before I can perform any programming.

Are there any resources that explain how to set up a custom board IDBLOCK based on the R4000 chip?

I know it is something to do with Write_IDBlock. But if I try to write a block similar to the RCM4110 (close to my board config) I am getting weird xmemcode colliding with rootdata errors. (Is there any way to debug the monstrosity that is MEMORY_LAYOUT.LIB defines?)