Build to target on custom board without ID block

[devotip]

I am dealing with a custom board that has no ID block data.
The targetless build is working well with the data I set in the project options and by downloading the binary with RFU utility i can confirm that the application is working.
If I do a build to target the build fails because the data retrieved from the custom board makes the compiler believes there is not enough memory.
I tried to define in the project options the memory size in 4k blocks as follow but that data is ignored
BOARD_TYPE=0xFFFF
FLASH_SIZE=64
RAM_SIZE=32
Is there a way to enforce ram and flash size when doing a build to target so that the compiler is happy and the debugger becomes available?

[tomlogic]

I think you'll need to define more macros. Is your board based on an existing module? You'd want to copy values from that module type, since there's conditional code in BOARDTYPES.LIB making use of the _BOARD_TYPE_ macro. You could add your own value

In Dynamic C 10, the Write ID Block program required declaration of many macros that the compiler normally sets using values from the System ID Block. For example, the RCM4200 has users setting the following:

	   _BOARD_TYPE_=RCM4200
	   _DC_CLK_DBL_=1
	   _DC_BRD_OPT0_=0x24
	   _DC_DFLASH0_=0x11701
	   _DC_MD0_=0x1
	   _DC_MD0_ID_=0xBFD7
	   _DC_MD0_TYPE_=0x1
	   _DC_MD0_SIZE_=0x80
	   _DC_MD0_SECSIZE_=0x1000
	   _DC_MD0_SECNUM_=0x80
	   _DC_MD0_SPEED_=0x46
	   _DC_MD0_MBC_=0x0
	   _DC_MD2_=0x1
	   _DC_MD2_ID_=0x0
	   _DC_MD2_TYPE_=0x0
	   _DC_MD2_SIZE_=0x80
	   _DC_MD2_SECSIZE_=0x0
	   _DC_MD2_SECNUM_=0x0
	   _DC_MD2_SPEED_=0xF
	   _DC_MD2_MBC_=0xC6
	   _DC_MD3_=0x1
	   _DC_MD3_ID_=0x0
	   _DC_MD3_TYPE_=0x0
	   _DC_MD3_SIZE_=0x80
	   _DC_MD3_SECSIZE_=0x0
	   _DC_MD3_SECNUM_=0x0
	   _DC_MD3_SPEED_=0x37
	   _DC_MD3_MBC_=0x45

I see similar macros from the BOARDTYPES.LIB file from Dynamic C 9. Without those, I don't think the BIOS will configure the memory quadrants correctly. You could create a C file to check whether those macros are defined, and print out the values. Then compile that as a binary, install it with RFU, and see what it prints out. Or use the attached boardinfo.c file and you can extract the values from the binary (see comments in that file for details on how).

Would it be possible to install a System ID Block on your custom device? You could then make changes to BOARDTYPES.LIB using your custom _BOARD_TYPE_ value, and you wouldn't need to add a bunch of macros to the Project file.

You might also want to take a look at memconfig.lib. It's possible that it's looking for more macro definitions to create the memory layout and device mapping. If you can provide some details on how it's not building correctly, I might be able to find some other resources for you.

boardinfo.c.zip

[devotip]

strings boardinfo.bin extracted the following macros, targetless bin built with the project definition that allows to produce the usable bin

=>MACRO CLOCK_DOUBLED=1
=>MACRO ENABLE_SPREADER=1
=>MACRO FLASH_WSTATES=0xc0
=>MACRO MB0CR_SETTING=0xc0 | 0x00 | (0<<4) | (0<<5)
=>MACRO MB1CR_SETTING=0xc0 | 0x02 | (0<<4) | (0<<5)
=>MACRO MB2CR_SETTING=0xc0 | 0x05 | (0<<4) | (0<<5)
=>MACRO MB3CR_SETTING=0xc0 | 0x05 | (0<<4) | (0<<5)
=>MACRO NUM_FLASH_WAITST=0
=>MACRO NUM_RAM2_WAITST=0
=>MACRO NUM_RAM_WAITST=0
=>MACRO RAM2_WSTATES=0xc0
=>MACRO RAM_WSTATES=0xc0
=>MACRO _DC_CLK_DBL_ undefined
=>MACRO _FREQ_DIV_19200_=30
=>MACRO _BOARD_TYPE_=0xFFFF

looks like the memory declarations are not getting into it
I would expect those too
_FLASH_SIZE_=64
_RAM_SIZE_=32

Yes, it is possible to rewrite the ID block, tried with the provided WRITE_IDBLOCK_920_962 but without favorable results.
DC9 is not finding the data or is not finding an acceptable id block version

The issue is only related to build to target where DC9 takes information from the target before building, my best guess now is that it is finding the erased flash data all FF and then choosing an inappropriate root code size

[devotip]

Added the printf for the other two macros and now they show up as expected

[devotip]

Is there documentation on the communication protocol to see what data is retrieved from the target?
I can gather the packets but I would like to not have to guess the packets structure.

[devotip]

Added to the application source the macro hints from your boardinfo to have the macro values in the actual condition of the failure
#warnt mac(FLASH_SIZE)
#warnt mac(RAM_SIZE)
and values are looking correct but yet it is failing

line   57 : WARNING UPDCLITE_UNI_2.C   : =>MACRO _FLASH_SIZE_=64        
line   58 : WARNING UPDCLITE_UNI_2.C   : =>MACRO _RAM_SIZE_=32          
line    1 : ERROR DKENTRY.LIB   : Out of root code space, try moving code to XMEM.

[tomlogic]

What do you use for Board ID in your RTI file? If you define the macro _BOARD_TYPE_ to that value, then BOARDTYPES.LIB should define all the macros you need. Since you can do target less compiles with the limited information from the RTI file, that must be the way it's defining the necessary macros.

[devotip]

Retrieved an original board to have a known reference, here is the output of block id dump for future use
2 0 1 1 1 0 13 50
1 1 0 0 10 b6 bf ff
ff 1 0 40 0 0 10 40
0 2d 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 1 0 0 0 20 0 37
0 3 0 0 0 c2 1 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 84 0 0 0 7c
3f 7c 3f 4c 0 55 aa 55
aa 55 aa

System ID Block content:

tableVersion = 2
productID = 0x0101
vendorID = 1
timestamp = 01/01/1980 00:00:16

flashID = 0xFFFFBFB6
flashType = 0x0001
flashSize = 256 Kbytes
sectorSize = 4096 bytes
numSectors = 64
flashSpeed = 45 nS

flash2ID = 0x00000000
flash2Type = 0x0000
flash2Size = 0 Kbytes
sector2Size = 0 bytes
num2Sectors = 0
flash2Speed = 0 nS

ramID = 0x00000001
ramSize = 128 Kbytes
ramSpeed = 55 nS

cpuID = Rabbit 2000 (rev. 3)
crystalFreq = 29.4912 MHz

macAddr = 00:00:00:00:00:00
serialNumber = ''
productName = ''

reserved[0] = 0x00

idBlockSize = 0x00000084 bytes
userBlockSize = 0x3F7C
userBlockLoc = 0x3F7C

idBlockCRC = 0x004C
marker = 55 AA 55 AA 55 AA

dumpboardid.c.txt

[tomlogic]

We already provide a sample program to dump the ID block.

And a program to write the ID block, that you could use to add an ID block to your custom board.

You had originally reported that you could compile to a .bin file, but not to your target without an ID block. Were you able to find a set of macros that allowed you to still compile to your board? It should be possible, because the Write ID Block program will work on a board without a valid ID block.

[devotip]

I have to wait to have again the board available, I am confident that with a reference valid data I can tinker the ID block content to overcome the issue of having the compiler misunderstanding the board memory size. By the way the system is kind of ready to manufacturing

[tomlogic]

If you write a System ID Block with the correct values to your custom board (using write_idblock_920_962.c), it will make it easier to use it with Dynamic C. You can also make use of the UserBlock APIs to store non-volatile data on the flash. Take a look at Samples/UserBlock to see what's possible there.

[devotip]

Now with the custom board available the little idblock data dump utility is showing all zeros which is consistent with the "insufficient memory" error, looks like there is something edgy about the flash handling in the bootloader. RFU can load the binary but the bootloader can't find the flash, so now digging about flash CS selection, any hint is appreciated.

[tomlogic]

@devotip, I don't think I mentioned it earlier, but the repository includes documentation of the bootstrapping process. Bootstrapping uses various probing techniques to locate RAM and flash in order to load software to the flash.

Is your custom board design based on one of Digi's Rabbit products? If so, you might be able to write an ID block just claiming to be that product. Is it a flash device listed in the flash.ini file? If not, you'll need to add it.

Are you sure you're actually reading the flash when you run your test program? If the memory mapping isn't correct, you could just be reading an idle memory bus. The Memory Management Unit section of the Rabbit 2000 Reference Poster shows how the CS, OE, and WE signals identify a memory device, and how you can then map those devices to the four memory quadrants of the memory controller. You can take a look at RCM2xxx schematics for some examples of how Digi's products mapped RAM and flash, and then look through BOARDTYPES.LIB to see how it configured the MBxCR registers.

[tomlogic]

@devotip, I wanted to check in and see how you're doing with this issue. Were you able to make any progress with information from my last comment?