Thanks Tom. That restored the ID Block.
Steve

From: "Tom Collins t...@tomlogic.com [rabbit-semi]"
To: r...
Sent: Friday, September 23, 2016 1:36 PM
Subject: Re: [rabbit-semi] Program Memory

Steve,
Try using Samples/write_idblock_920_962.c to replace the missing SystemIDBlock.
https://github.com/digidotcom/DCRabbit_9/blob/master/Samples/write_idblock_920_962.c
-Tom

On Sep 23, 2016, at 1:30 PM, s...@yahoo.com [rabbit-semi] wrote:

I then found a file named CHANGE_USERBLOCK.C that I had downloaded from the files section of this group years ago. The code was posted in 2002. I compiled it and ran it. It says that it was successful at changing the ID block. But when it read the ID block with _readIDBlock() it returns error -3, invalid checksum.
I ran idblock_report.c again and now it says the module has no ID block. Toast!
#yiv5226991133 #yiv5226991133 -- #yiv5226991133ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv5226991133 #yiv5226991133ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv5226991133 #yiv5226991133ygrp-mkp #yiv5226991133hd {color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;}#yiv5226991133 #yiv5226991133ygrp-mkp #yiv5226991133ads {margin-bottom:10px;}#yiv5226991133 #yiv5226991133ygrp-mkp .yiv5226991133ad {padding:0 0;}#yiv5226991133 #yiv5226991133ygrp-mkp .yiv5226991133ad p {margin:0;}#yiv5226991133 #yiv5226991133ygrp-mkp .yiv5226991133ad a {color:#0000ff;text-decoration:none;}#yiv5226991133 #yiv5226991133ygrp-sponsor #yiv5226991133ygrp-lc {font-family:Arial;}#yiv5226991133 #yiv5226991133ygrp-sponsor #yiv5226991133ygrp-lc #yiv5226991133hd {margin:10px 0px;font-weight:700;font-size:78%;line-height:122%;}#yiv5226991133 #yiv5226991133ygrp-sponsor #yiv5226991133ygrp-lc .yiv5226991133ad {margin-bottom:10px;padding:0 0;}#yiv5226991133 #yiv5226991133actions {font-family:Verdana;font-size:11px;padding:10px 0;}#yiv5226991133 #yiv5226991133activity {background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv5226991133 #yiv5226991133activity span {font-weight:700;}#yiv5226991133 #yiv5226991133activity span:first-child {text-transform:uppercase;}#yiv5226991133 #yiv5226991133activity span a {color:#5085b6;text-decoration:none;}#yiv5226991133 #yiv5226991133activity span span {color:#ff7900;}#yiv5226991133 #yiv5226991133activity span .yiv5226991133underline {text-decoration:underline;}#yiv5226991133 .yiv5226991133attach {clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 0;width:400px;}#yiv5226991133 .yiv5226991133attach div a {text-decoration:none;}#yiv5226991133 .yiv5226991133attach img {border:none;padding-right:5px;}#yiv5226991133 .yiv5226991133attach label {display:block;margin-bottom:5px;}#yiv5226991133 .yiv5226991133attach label a {text-decoration:none;}#yiv5226991133 blockquote {margin:0 0 0 4px;}#yiv5226991133 .yiv5226991133bold {font-family:Arial;font-size:13px;font-weight:700;}#yiv5226991133 .yiv5226991133bold a {text-decoration:none;}#yiv5226991133 dd.yiv5226991133last p a {font-family:Verdana;font-weight:700;}#yiv5226991133 dd.yiv5226991133last p span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv5226991133 dd.yiv5226991133last p span.yiv5226991133yshortcuts {margin-right:0;}#yiv5226991133 div.yiv5226991133attach-table div div a {text-decoration:none;}#yiv5226991133 div.yiv5226991133attach-table {width:400px;}#yiv5226991133 div.yiv5226991133file-title a, #yiv5226991133 div.yiv5226991133file-title a:active, #yiv5226991133 div.yiv5226991133file-title a:hover, #yiv5226991133 div.yiv5226991133file-title a:visited {text-decoration:none;}#yiv5226991133 div.yiv5226991133photo-title a, #yiv5226991133 div.yiv5226991133photo-title a:active, #yiv5226991133 div.yiv5226991133photo-title a:hover, #yiv5226991133 div.yiv5226991133photo-title a:visited {text-decoration:none;}#yiv5226991133 div#yiv5226991133ygrp-mlmsg #yiv5226991133ygrp-msg p a span.yiv5226991133yshortcuts {font-family:Verdana;font-size:10px;font-weight:normal;}#yiv5226991133 .yiv5226991133green {color:#628c2a;}#yiv5226991133 .yiv5226991133MsoNormal {margin:0 0 0 0;}#yiv5226991133 o {font-size:0;}#yiv5226991133 #yiv5226991133photos div {float:left;width:72px;}#yiv5226991133 #yiv5226991133photos div div {border:1px solid #666666;min-height:62px;overflow:hidden;width:62px;}#yiv5226991133 #yiv5226991133photos div label {color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv5226991133 #yiv5226991133reco-category {font-size:77%;}#yiv5226991133 #yiv5226991133reco-desc {font-size:77%;}#yiv5226991133 .yiv5226991133replbq {margin:4px;}#yiv5226991133 #yiv5226991133ygrp-actbar div a:first-child {margin-right:2px;padding-right:5px;}#yiv5226991133 #yiv5226991133ygrp-mlmsg {font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv5226991133 #yiv5226991133ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv5226991133 #yiv5226991133ygrp-mlmsg select, #yiv5226991133 input, #yiv5226991133 textarea {font:99% Arial, Helvetica, clean, sans-serif;}#yiv5226991133 #yiv5226991133ygrp-mlmsg pre, #yiv5226991133 code {font:115% monospace;}#yiv5226991133 #yiv5226991133ygrp-mlmsg * {line-height:1.22em;}#yiv5226991133 #yiv5226991133ygrp-mlmsg #yiv5226991133logo {padding-bottom:10px;}#yiv5226991133 #yiv5226991133ygrp-msg p a {font-family:Verdana;}#yiv5226991133 #yiv5226991133ygrp-msg p#yiv5226991133attach-count span {color:#1E66AE;font-weight:700;}#yiv5226991133 #yiv5226991133ygrp-reco #yiv5226991133reco-head {color:#ff7900;font-weight:700;}#yiv5226991133 #yiv5226991133ygrp-reco {margin-bottom:20px;padding:0px;}#yiv5226991133 #yiv5226991133ygrp-sponsor #yiv5226991133ov li a {font-size:130%;text-decoration:none;}#yiv5226991133 #yiv5226991133ygrp-sponsor #yiv5226991133ov li {font-size:77%;list-style-type:square;padding:6px 0;}#yiv5226991133 #yiv5226991133ygrp-sponsor #yiv5226991133ov ul {margin:0;padding:0 0 0 8px;}#yiv5226991133 #yiv5226991133ygrp-text {font-family:Georgia;}#yiv5226991133 #yiv5226991133ygrp-text p {margin:0 0 1em 0;}#yiv5226991133 #yiv5226991133ygrp-text tt {font-size:120%;}#yiv5226991133 #yiv5226991133ygrp-vital ul li:last-child {border-right:none !important;}#yiv5226991133

Steve,

Try using Samples/write_idblock_920_962.c to replace the missing SystemIDBlock.

https://github.com/digidotcom/DCRabbit_9/blob/master/Samples/write_idblock_920_962.c

-Tom
On Sep 23, 2016, at 1:30 PM, s...@yahoo.com [rabbit-semi] wrote:

> I then found a file named CHANGE_USERBLOCK.C that I had downloaded from the files section of this group years ago. The code was posted in 2002. I compiled it and ran it. It says that it was successful at changing the ID block. But when it read the ID block with _readIDBlock() it returns error -3, invalid checksum.
>
> I ran idblock_report.c again and now it says the module has no ID block. Toast!

I believe you and Tom. I just think it's odd that the comments in the bios file only say to change MAX_USERBLOCK_SIZE to change the size of the userblock. Nothing about having to change the ID block.

In any case, I ran sample program idblock_report.c and saved the ID block configuration it printed.

I then found a file named CHANGE_USERBLOCK.C that I had downloaded from the files section of this group years ago. The code was posted in 2002. I compiled it and ran it. It says that it was successful at changing the ID block. But when it read the ID block with _readIDBlock() it returns error -3, invalid checksum.

I ran idblock_report.c again and now it says the module has no ID block. Toast!

On 9/22/2016 12:31 PM, s...@yahoo.com [rabbit-semi] wrote:
>
> I set MAX_USERBLOCK_SIZE to zero, removed the size test, and compiled
> with no errors. But the program doesn't run.
>
> Changed MAX_USERBLOCK_SIZE to 0x2000, the minimum size, recompiled
> with no errors. Program still doesn't run.
>
> Leaving MAX_USERBLOCK_SIZE unchanged at 0x2000, reduced my code to
> 494496 bytes sent from 500164. Program runs.

The RFU will see the user block in the ID block of the board and ignore
the area.

As Tom said, you will have to rewrite the ID block on the board to use
less area.

--
------
Scott G. Henion, Consultant
Web site: http://SHDesigns.org
------

I set MAX_USERBLOCK_SIZE to zero, removed the size test, and compiled with no errors. But the program doesn't run.
Changed MAX_USERBLOCK_SIZE to 0x2000, the minimum size, recompiled with no errors. Program still doesn't run.
Leaving MAX_USERBLOCK_SIZE unchanged at 0x2000, reduced my code to 494496 bytes sent from 500164. Program runs.

I think that in addition to making that change, you'll need to rewrite the SystemIDBlock on all of your boards with fields indicating that you have a single, unmirrored 4KB UserBlock (which contains the SystemIDBlock at the end) on your board.

I'm not sure how easy it will be to do that. You should definitely be able to tell it you have two, mirrored 4KB UserBlocks, and you're only losing 4KB of flash space to do so. Less hacking required, and less chance of something going wrong.

-Tom
On Sep 22, 2016, at 9:08 AM, s...@yahoo.com [rabbit-semi] wrote:

> MAX_USERBLOCK_SIZE is defined in StdBios.c. The comments say it can be reduced to 0x1000. But a few lines later, there is a test of MAX_USERBLOCK_SIZE to make sure it is at least 0x2000 in size, if not it throws a compile error.
>
> Since I am not using the userblock, and never have, nor am I using the file system, is there a problem with removing the size test, or even setting MAX_USERBLOCK_SIZE to zero?
>
> I'm using DC v9.62.
>

MAX_USERBLOCK_SIZE is defined in StdBios.c. The comments say it can be reduced to 0x1000. But a few lines later, there is a test of MAX_USERBLOCK_SIZE to make sure it is at least 0x2000 in size, if not it throws a compile error.

Since I am not using the userblock, and never have, nor am I using the file system, is there a problem with removing the size test, or even setting MAX_USERBLOCK_SIZE to zero?

I'm using DC v9.62.

I totally forgot about the user block. I never use it, so I don't think about it.
Steve

From: "'Tom Collins' t...@tomlogic.com [rabbit-semi]"
To: r...
Sent: Wednesday, September 21, 2016 12:41 PM
Subject: RE: [rabbit-semi] Program Memory

Hopefully this will provide enough information to help with your situation. First off, even though the board has a 512KB flash, the very top of the flash holds a System ID Block with board information, including its MAC address. Below that, there are typically mirrored UserBlocks for program storage. It is possible to resize the UserBlock to free up more space. I might be able to track down the technique I used on an RCM2200 product – as I recall it required customers to install a specific firmware build that would do the resizing, and then there would be enough room to install later firmware versions. I’m not sure how RFU counts bytes, but it does need to bootstrap the processor in a multi-step process that involves sending a pilot BIOS capable of receiving firmware and writing it to flash. That likely explains the larger byte count. Anyone curious about the bootstrap process might want to read the documentation I wrote for how Dynamic C 10 does it (https://github.com/digidotcom/DCRabbit_10/commit/0d642ee1028b007d5fe1856c2248ede3ba48f13d). I imagine DC 9 is similar. Your last working build was 447.21KB. The build that broke was 452.98KB. If the RCM3900 uses a mirrored 16KB UserBlock (with the SystemIDBlock potentially embedded at the top), that would allow for a 448KB program. My guess is that the compiler isn’t giving you a warning because you have MAX_USERBLOCK_SIZE set to something other than the default of 0x8000 (32KB), but your board actually has 32KB allocated for the UserBlock. -Tom From: r... [mailto:r...]
Sent: Wednesday, September 21, 2016 8:54 AM
To: r...
Subject: [rabbit-semi] Program Memory I think some of this has been talked about before, but I'm not finding any answers, just flames. I have an application that runs on an RCM3900. Over the years the size of the app has increased
little by little as features were added. Yesterday I made the latest change, programmed a module, and nothing. Program wouldn't run. I
backed out the change and it runs. I add the change back in and remove a different feature. It runs.According to DC, the total code size without the new changes, and that runs, is 457939. When I download
the program, the RFU says it's sending 494520 bytes. When I add the new feature back in, DC reports total code size of 463850 bytes. RFU says it's sending
500164 bytes. First question, what makes up the difference between what DC reports and the RFU reports for size?
Is the extra 36k the RabbitBios and that it's not included in the total code size DC reports? Second question, since program memory is 512K, which is really 524288 bytes, why does the program quit
running when I get close to 500k bytes? Is this a compiler bug or is there something put there by DC? Note, I'm using DC 9.62, runtime checking disabled, and debug disabled. #yiv6979150538 #yiv6979150538 -- #yiv6979150538ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv6979150538 #yiv6979150538ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv6979150538 #yiv6979150538ygrp-mkp #yiv6979150538hd {color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;}#yiv6979150538 #yiv6979150538ygrp-mkp #yiv6979150538ads {margin-bottom:10px;}#yiv6979150538 #yiv6979150538ygrp-mkp .yiv6979150538ad {padding:0 0;}#yiv6979150538 #yiv6979150538ygrp-mkp .yiv6979150538ad p {margin:0;}#yiv6979150538 #yiv6979150538ygrp-mkp .yiv6979150538ad a {color:#0000ff;text-decoration:none;}#yiv6979150538 #yiv6979150538ygrp-sponsor #yiv6979150538ygrp-lc {font-family:Arial;}#yiv6979150538 #yiv6979150538ygrp-sponsor #yiv6979150538ygrp-lc #yiv6979150538hd {margin:10px 0px;font-weight:700;font-size:78%;line-height:122%;}#yiv6979150538 #yiv6979150538ygrp-sponsor #yiv6979150538ygrp-lc .yiv6979150538ad {margin-bottom:10px;padding:0 0;}#yiv6979150538 #yiv6979150538actions {font-family:Verdana;font-size:11px;padding:10px 0;}#yiv6979150538 #yiv6979150538activity {background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv6979150538 #yiv6979150538activity span {font-weight:700;}#yiv6979150538 #yiv6979150538activity span:first-child {text-transform:uppercase;}#yiv6979150538 #yiv6979150538activity span a {color:#5085b6;text-decoration:none;}#yiv6979150538 #yiv6979150538activity span span {color:#ff7900;}#yiv6979150538 #yiv6979150538activity span .yiv6979150538underline {text-decoration:underline;}#yiv6979150538 .yiv6979150538attach {clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 0;width:400px;}#yiv6979150538 .yiv6979150538attach div a {text-decoration:none;}#yiv6979150538 .yiv6979150538attach img {border:none;padding-right:5px;}#yiv6979150538 .yiv6979150538attach label {display:block;margin-bottom:5px;}#yiv6979150538 .yiv6979150538attach label a {text-decoration:none;}#yiv6979150538 blockquote {margin:0 0 0 4px;}#yiv6979150538 .yiv6979150538bold {font-family:Arial;font-size:13px;font-weight:700;}#yiv6979150538 .yiv6979150538bold a {text-decoration:none;}#yiv6979150538 dd.yiv6979150538last p a {font-family:Verdana;font-weight:700;}#yiv6979150538 dd.yiv6979150538last p span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv6979150538 dd.yiv6979150538last p span.yiv6979150538yshortcuts {margin-right:0;}#yiv6979150538 div.yiv6979150538attach-table div div a {text-decoration:none;}#yiv6979150538 div.yiv6979150538attach-table {width:400px;}#yiv6979150538 div.yiv6979150538file-title a, #yiv6979150538 div.yiv6979150538file-title a:active, #yiv6979150538 div.yiv6979150538file-title a:hover, #yiv6979150538 div.yiv6979150538file-title a:visited {text-decoration:none;}#yiv6979150538 div.yiv6979150538photo-title a, #yiv6979150538 div.yiv6979150538photo-title a:active, #yiv6979150538 div.yiv6979150538photo-title a:hover, #yiv6979150538 div.yiv6979150538photo-title a:visited {text-decoration:none;}#yiv6979150538 div#yiv6979150538ygrp-mlmsg #yiv6979150538ygrp-msg p a span.yiv6979150538yshortcuts {font-family:Verdana;font-size:10px;font-weight:normal;}#yiv6979150538 .yiv6979150538green {color:#628c2a;}#yiv6979150538 .yiv6979150538MsoNormal {margin:0 0 0 0;}#yiv6979150538 o {font-size:0;}#yiv6979150538 #yiv6979150538photos div {float:left;width:72px;}#yiv6979150538 #yiv6979150538photos div div {border:1px solid #666666;min-height:62px;overflow:hidden;width:62px;}#yiv6979150538 #yiv6979150538photos div label {color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv6979150538 #yiv6979150538reco-category {font-size:77%;}#yiv6979150538 #yiv6979150538reco-desc {font-size:77%;}#yiv6979150538 .yiv6979150538replbq {margin:4px;}#yiv6979150538 #yiv6979150538ygrp-actbar div a:first-child {margin-right:2px;padding-right:5px;}#yiv6979150538 #yiv6979150538ygrp-mlmsg {font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv6979150538 #yiv6979150538ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv6979150538 #yiv6979150538ygrp-mlmsg select, #yiv6979150538 input, #yiv6979150538 textarea {font:99% Arial, Helvetica, clean, sans-serif;}#yiv6979150538 #yiv6979150538ygrp-mlmsg pre, #yiv6979150538 code {font:115% monospace;}#yiv6979150538 #yiv6979150538ygrp-mlmsg * {line-height:1.22em;}#yiv6979150538 #yiv6979150538ygrp-mlmsg #yiv6979150538logo {padding-bottom:10px;}#yiv6979150538 #yiv6979150538ygrp-msg p a {font-family:Verdana;}#yiv6979150538 #yiv6979150538ygrp-msg p#yiv6979150538attach-count span {color:#1E66AE;font-weight:700;}#yiv6979150538 #yiv6979150538ygrp-reco #yiv6979150538reco-head {color:#ff7900;font-weight:700;}#yiv6979150538 #yiv6979150538ygrp-reco {margin-bottom:20px;padding:0px;}#yiv6979150538 #yiv6979150538ygrp-sponsor #yiv6979150538ov li a {font-size:130%;text-decoration:none;}#yiv6979150538 #yiv6979150538ygrp-sponsor #yiv6979150538ov li {font-size:77%;list-style-type:square;padding:6px 0;}#yiv6979150538 #yiv6979150538ygrp-sponsor #yiv6979150538ov ul {margin:0;padding:0 0 0 8px;}#yiv6979150538 #yiv6979150538ygrp-text {font-family:Georgia;}#yiv6979150538 #yiv6979150538ygrp-text p {margin:0 0 1em 0;}#yiv6979150538 #yiv6979150538ygrp-text tt {font-size:120%;}#yiv6979150538 #yiv6979150538ygrp-vital ul li:last-child {border-right:none !important;}#yiv6979150538

Hopefully this will provide enough information to help with your situation.

First off, even though the board has a 512KB flash, the very top of the flash holds a System ID Block with board information, including its MAC address. Below that, there are typically mirrored UserBlocks for program storage.

It is possible to resize the UserBlock to free up more space. I might be able to track down the technique I used on an RCM2200 product – as I recall it required customers to install a specific firmware build that would do the resizing, and then there would be enough room to install later firmware versions.

I’m not sure how RFU counts bytes, but it does need to bootstrap the processor in a multi-step process that involves sending a pilot BIOS capable of receiving firmware and writing it to flash. That likely explains the larger byte count. Anyone curious about the bootstrap process might want to read the documentation I wrote for how Dynamic C 10 does it (https://github.com/digidotcom/DCRabbit_10/commit/0d642ee1028b007d5fe1856c2248ede3ba48f13d). I imagine DC 9 is similar.

Your last working build was 447.21KB. The build that broke was 452.98KB. If the RCM3900 uses a mirrored 16KB UserBlock (with the SystemIDBlock potentially embedded at the top), that would allow for a 448KB program.

My guess is that the compiler isn’t giving you a warning because you have MAX_USERBLOCK_SIZE set to something other than the default of 0x8000 (32KB), but your board actually has 32KB allocated for the UserBlock.

-Tom

From: r... [mailto:r...]
Sent: Wednesday, September 21, 2016 8:54 AM
To: r...
Subject: [rabbit-semi] Program Memory

I think some of this has been talked about before, but I'm not finding any answers, just flames.

I have an application that runs on an RCM3900. Over the years the size of the app has increased
little by little as features were added.

Yesterday I made the latest change, programmed a module, and nothing. Program wouldn't run. I
backed out the change and it runs. I add the change back in and remove a different feature. It runs.

According to DC, the total code size without the new changes, and that runs, is 457939. When I download
the program, the RFU says it's sending 494520 bytes.

When I add the new feature back in, DC reports total code size of 463850 bytes. RFU says it's sending
500164 bytes.

First question, what makes up the difference between what DC reports and the RFU reports for size?
Is the extra 36k the RabbitBios and that it's not included in the total code size DC reports?

Second question, since program memory is 512K, which is really 524288 bytes, why does the program quit
running when I get close to 500k bytes? Is this a compiler bug or is there something put there by DC?

Note, I'm using DC 9.62, runtime checking disabled, and debug disabled.