Does writeUserBlock crash SysIdBlock on RCM3000 ?
I wrote some bytes with writeUserBlock and read them back, OK.
Now my SysIdBlock had a marker[5] == 0x00.
I used write_idblock with MYBOARD defined to RCM3000 to correct this.
Now DC7.33P compiles but does not run any program.
I get "Timeout while waiting for response from target" after
compilation.
How can I do a recovery of my RCM3000 board ?
Thomas
userblock usage RCM3000
Started by ●August 21, 2003
Reply by ●August 21, 20032003-08-21
When you say ". . . SysIDBlock had a marker[5] == 0." are you
referring to
the SysIDBlock structure in SRAM that is initially copied from flash, or
(one of) the ID Block(s) stored at the top of the first flash?
If the former, and not just when temporarily changed in the write_idblock.c
utility itself, then there certainly seems to be a problem and I'm not sure
how it would be caused, except by some errant code (bad pointer, runaway,
etc.).
If the latter, and if the ID/User Blocks are mirrored (ie: version 3 or 4
ID Block), then it is normal for the "invalid" image's marker[5] == 0x00,
while the "valid" image's marker[5] == 0xAA. The two images alternate
between "valid" and "invalid" at each write to the User Block, with
marker[5] being the only difference between the images.
Recent versions of the write_idblock.c utility, when writing a version 3 or
4 (mirrored) ID Block with User Block of nonzero size, actually write both
"valid" and "invalid" copies of the ID Block. If writing a version 1 or 2
(non-mirrored) ID Block or any version ID Block with no User Block
(ie: zero size) then only one ID Block is written, at the very top of the
first flash.
Can you run any program at all, such as a standard Dynamic C sample that
doesn't call writeUserBlock? If not, then something probably went wrong
with the write_idblock.c utility.
The only time I have seen anything similar is when I have accidentally
written a non-RCM3200 board type into an RCM3200 (or derivative) target, or
vice versa. These board types, when incorrectly written to a target's
flash, mess up Dynamic C's BIOS because of the RCM3200's "unusual" memory
device mapping.
What happens if you let the RCM3000 sit (unpowered) to cool off for a
while? Can you run any program then?
- Bruce
At 10:17 AM 8/21/03, you wrote:
>Does writeUserBlock crash SysIdBlock on RCM3000 ?
>
>I wrote some bytes with writeUserBlock and read them back, OK.
>Now my SysIdBlock had a marker[5] == 0x00.
>I used write_idblock with MYBOARD defined to RCM3000 to correct this.
>Now DC7.33P compiles but does not run any program.
>I get "Timeout while waiting for response from target" after
>compilation.
>
>How can I do a recovery of my RCM3000 board ?
>
>Thomas >
>
>To unsubscribe from this group, send an email to:
>rabbit-semi-unsubscribe@rabb... >
>">http://docs.yahoo.com/info/terms/
the SysIDBlock structure in SRAM that is initially copied from flash, or
(one of) the ID Block(s) stored at the top of the first flash?
If the former, and not just when temporarily changed in the write_idblock.c
utility itself, then there certainly seems to be a problem and I'm not sure
how it would be caused, except by some errant code (bad pointer, runaway,
etc.).
If the latter, and if the ID/User Blocks are mirrored (ie: version 3 or 4
ID Block), then it is normal for the "invalid" image's marker[5] == 0x00,
while the "valid" image's marker[5] == 0xAA. The two images alternate
between "valid" and "invalid" at each write to the User Block, with
marker[5] being the only difference between the images.
Recent versions of the write_idblock.c utility, when writing a version 3 or
4 (mirrored) ID Block with User Block of nonzero size, actually write both
"valid" and "invalid" copies of the ID Block. If writing a version 1 or 2
(non-mirrored) ID Block or any version ID Block with no User Block
(ie: zero size) then only one ID Block is written, at the very top of the
first flash.
Can you run any program at all, such as a standard Dynamic C sample that
doesn't call writeUserBlock? If not, then something probably went wrong
with the write_idblock.c utility.
The only time I have seen anything similar is when I have accidentally
written a non-RCM3200 board type into an RCM3200 (or derivative) target, or
vice versa. These board types, when incorrectly written to a target's
flash, mess up Dynamic C's BIOS because of the RCM3200's "unusual" memory
device mapping.
What happens if you let the RCM3000 sit (unpowered) to cool off for a
while? Can you run any program then?
- Bruce
At 10:17 AM 8/21/03, you wrote:
>Does writeUserBlock crash SysIdBlock on RCM3000 ?
>
>I wrote some bytes with writeUserBlock and read them back, OK.
>Now my SysIdBlock had a marker[5] == 0x00.
>I used write_idblock with MYBOARD defined to RCM3000 to correct this.
>Now DC7.33P compiles but does not run any program.
>I get "Timeout while waiting for response from target" after
>compilation.
>
>How can I do a recovery of my RCM3000 board ?
>
>Thomas >
>
>To unsubscribe from this group, send an email to:
>rabbit-semi-unsubscribe@rabb... >
>">http://docs.yahoo.com/info/terms/
Reply by ●August 21, 20032003-08-21
With an other compiler (only reads from flash) I can
see this output from my program :
--------------------
pSysIDBlockTail->idBlockSize : 132, addr : ffff0
000ffff0 84 00 00 00 7C 5F 7C 5F 9F AA 55 AA 55 AA 55 AA ....|_|_..U.U.U.
pSysIDBlockTail->idBlockSize : -1, addr : bfff0
000bfff0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
pSysIDBlockTail->idBlockSize : 539936478, addr : 7fff0
0007fff0 DE C6 2E 20 9B 51 C2 52 B8 09 BA D2 B8 1A DC CB ... .Q.R........
pSysIDBlockTail->idBlockSize : 539936478, addr : 3fff0
0003fff0 DE C6 2E 20 9B 51 C2 52 B8 09 BA D2 B8 1A DC CB ... .Q.R........
i1 : 0
found at : fff7c
mySysIDBlock: 0
tableVersion : 2
productID : 3840
vendorID : 1
timestamp : 20499
13 50 01 0f 08 25 08
flashID : ffffbfd7
flashType : 1
flashSize : 128 1000h pages
sectorSize : 4096 bytes
numSectors : 128
flashSpeed : 0 ns
flash2ID : ffffbfd7
flash2Type : 1
flash2Size : 128 1000h pages
sector2Size : 4096 bytes
num2Sectors : 128
flash2Speed : 0 ns
ramID : 1
ramSize : 128 1000h pages
ramSpeed[ns] : 0 ns
cpuID : 256
crystalFreq[Hz] : 22118400 Hz
macAddr[6] : 00 90 C2 C0 EC 67
serialNumber :
productName :
reserved : 0
idBlockSize : 132
userBlockSize : 24444
userBlockLoc : 24444
marker : 55 AA 55 AA 55 AA
--------------------
a valid block is at 0x000ffff0
there is also the correct MAC-address I've changed in write_idblock
to the address the board was delivered with.
but the table version is now 2! it was 4 before.
I've tested the whole procedure with a cheaper RCM3110 module,
all went OK.
The last Messages I get from statusline after compile is :
"Getting enabled options"
"Closing connection"
>>From: Bruce Isted <bisted@z...>
>>Date: Thu Aug 21, 2003 11:22 am
>>Subject: Re: [rabbit-semi] userblock usage RCM3000
>>When you say ". . . SysIDBlock had a marker[5] ==
>>0." are you referring to
>>the SysIDBlock structure in SRAM that is initially
>>copied from flash, or
>>(one of) the ID Block(s) stored at the top of the
>>first flash?
it seems it was the SysIDBlock structure in SRAM.
searching in flash the only one I found in [ffff0,bfff0,7fff0,3fff0]
has 0xAA (see above).
>>If the former, and not just when temporarily
>>changed in the write_idblock.c
>>utility itself, then there certainly seems to be a
>>problem and I'm not sure
>>how it would be caused, except by some errant code
>>(bad pointer, runaway,
>>etc.).
>>If the latter, and if the ID/User Blocks are mirrored (ie: version 3 or 4
>>ID Block), then it is normal for the "invalid" image's marker[5] == 0x00,
>>while the "valid" image's marker[5] == 0xAA. The two images alternate
>>between "valid" and "invalid" at each write to the User Block, with
>>marker[5] being the only difference between the images.
>>Recent versions of the write_idblock.c utility, when writing a version 3 or
>>4 (mirrored) ID Block with User Block of nonzero size, actually write both
>>"valid" and "invalid" copies of the ID Block. If writing a version 1 or 2
>>(non-mirrored) ID Block or any version ID Block with no User Block
>>(ie: zero size) then only one ID Block is written, at the very top of the
>>first flash.
>>Can you run any program at all, such as a standard Dynamic C sample that
>>doesn't call writeUserBlock? If not, then something probably went wrong
>>with the write_idblock.c utility.
Not even Hello world is running.
>>The only time I have seen anything similar is when I have accidentally
>>written a non-RCM3200 board type into an RCM3200 (or derivative) target, or
>>vice versa. These board types, when incorrectly written to a target's
>>flash, mess up Dynamic C's BIOS because of the RCM3200's "unusual" memory
>>device mapping.
>>What happens if you let the RCM3000 sit (unpowered) to cool off for a
>>while? Can you run any program then?
No improvement. >> - Bruce
>> At 10:17 AM 8/21/03, you wrote:
>> >Does writeUserBlock crash SysIdBlock on RCM3000 ?
>> >
>> >I wrote some bytes with writeUserBlock and read them back, OK.
>> >Now my SysIdBlock had a marker[5] == 0x00.
>> >I used write_idblock with MYBOARD defined to RCM3000 to correct this.
>> >Now DC7.33P compiles but does not run any program.
>> >I get "Timeout while waiting for response from target" after
>> >compilation.
>> >
>> >How can I do a recovery of my RCM3000 board ?
>> >
>> >Thomas
Thomas
see this output from my program :
--------------------
pSysIDBlockTail->idBlockSize : 132, addr : ffff0
000ffff0 84 00 00 00 7C 5F 7C 5F 9F AA 55 AA 55 AA 55 AA ....|_|_..U.U.U.
pSysIDBlockTail->idBlockSize : -1, addr : bfff0
000bfff0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
pSysIDBlockTail->idBlockSize : 539936478, addr : 7fff0
0007fff0 DE C6 2E 20 9B 51 C2 52 B8 09 BA D2 B8 1A DC CB ... .Q.R........
pSysIDBlockTail->idBlockSize : 539936478, addr : 3fff0
0003fff0 DE C6 2E 20 9B 51 C2 52 B8 09 BA D2 B8 1A DC CB ... .Q.R........
i1 : 0
found at : fff7c
mySysIDBlock: 0
tableVersion : 2
productID : 3840
vendorID : 1
timestamp : 20499
13 50 01 0f 08 25 08
flashID : ffffbfd7
flashType : 1
flashSize : 128 1000h pages
sectorSize : 4096 bytes
numSectors : 128
flashSpeed : 0 ns
flash2ID : ffffbfd7
flash2Type : 1
flash2Size : 128 1000h pages
sector2Size : 4096 bytes
num2Sectors : 128
flash2Speed : 0 ns
ramID : 1
ramSize : 128 1000h pages
ramSpeed[ns] : 0 ns
cpuID : 256
crystalFreq[Hz] : 22118400 Hz
macAddr[6] : 00 90 C2 C0 EC 67
serialNumber :
productName :
reserved : 0
idBlockSize : 132
userBlockSize : 24444
userBlockLoc : 24444
marker : 55 AA 55 AA 55 AA
--------------------
a valid block is at 0x000ffff0
there is also the correct MAC-address I've changed in write_idblock
to the address the board was delivered with.
but the table version is now 2! it was 4 before.
I've tested the whole procedure with a cheaper RCM3110 module,
all went OK.
The last Messages I get from statusline after compile is :
"Getting enabled options"
"Closing connection"
>>From: Bruce Isted <bisted@z...>
>>Date: Thu Aug 21, 2003 11:22 am
>>Subject: Re: [rabbit-semi] userblock usage RCM3000
>>When you say ". . . SysIDBlock had a marker[5] ==
>>0." are you referring to
>>the SysIDBlock structure in SRAM that is initially
>>copied from flash, or
>>(one of) the ID Block(s) stored at the top of the
>>first flash?
it seems it was the SysIDBlock structure in SRAM.
searching in flash the only one I found in [ffff0,bfff0,7fff0,3fff0]
has 0xAA (see above).
>>If the former, and not just when temporarily
>>changed in the write_idblock.c
>>utility itself, then there certainly seems to be a
>>problem and I'm not sure
>>how it would be caused, except by some errant code
>>(bad pointer, runaway,
>>etc.).
>>If the latter, and if the ID/User Blocks are mirrored (ie: version 3 or 4
>>ID Block), then it is normal for the "invalid" image's marker[5] == 0x00,
>>while the "valid" image's marker[5] == 0xAA. The two images alternate
>>between "valid" and "invalid" at each write to the User Block, with
>>marker[5] being the only difference between the images.
>>Recent versions of the write_idblock.c utility, when writing a version 3 or
>>4 (mirrored) ID Block with User Block of nonzero size, actually write both
>>"valid" and "invalid" copies of the ID Block. If writing a version 1 or 2
>>(non-mirrored) ID Block or any version ID Block with no User Block
>>(ie: zero size) then only one ID Block is written, at the very top of the
>>first flash.
>>Can you run any program at all, such as a standard Dynamic C sample that
>>doesn't call writeUserBlock? If not, then something probably went wrong
>>with the write_idblock.c utility.
Not even Hello world is running.
>>The only time I have seen anything similar is when I have accidentally
>>written a non-RCM3200 board type into an RCM3200 (or derivative) target, or
>>vice versa. These board types, when incorrectly written to a target's
>>flash, mess up Dynamic C's BIOS because of the RCM3200's "unusual" memory
>>device mapping.
>>What happens if you let the RCM3000 sit (unpowered) to cool off for a
>>while? Can you run any program then?
No improvement. >> - Bruce
>> At 10:17 AM 8/21/03, you wrote:
>> >Does writeUserBlock crash SysIdBlock on RCM3000 ?
>> >
>> >I wrote some bytes with writeUserBlock and read them back, OK.
>> >Now my SysIdBlock had a marker[5] == 0x00.
>> >I used write_idblock with MYBOARD defined to RCM3000 to correct this.
>> >Now DC7.33P compiles but does not run any program.
>> >I get "Timeout while waiting for response from target" after
>> >compilation.
>> >
>> >How can I do a recovery of my RCM3000 board ?
>> >
>> >Thomas
Thomas
Reply by ●August 22, 20032003-08-22
The write_idblock.c utility you used may be an older one, where you have to
search for the ID Block version assignment in the body of the program code
and edit in the desired value. I notice that your program shows the User
Block size/offset is set to 24444 (decimal, or 0x5F7C), giving a total of a
24KB combined ID/User Block. This is another nonstandard value, I presume
your write_idblock.c utility has been modified to set this size?
What are the values of the MBxCRShadow registers when your program
runs? I'm going to assume that your program runs in RAM in the MB0CR+MB1CR
quadrants and and maps the RCM3000's first (/CS0) flash into the MB2CR
quadrant and its second (/CS2) flash into the MB3CR quadrant.
If this assumption is true, then your ID Block is located at the top of the
RCM3000's second flash, and the standard Dynamic C BIOS's flash init
library routines will not find it there, but they may be finding a mirrored
image of a version 3 or 4 ID Block located just below the top of flash
minus one of 8KB, 16KB, or 24KB.
It looks like you can run a program in RAM using the other (Softools?)
compiler, is that right? Can Dynamic C also load and run a program in
RAM? If so, I can send you directly (off-list) an updated version of the
write_idblock.c utility that will run in RAM to place ID Block(s) at the
top of the first flash.
- Bruce
At 03:08 AM 8/22/03, you wrote:
>With an other compiler (only reads from flash) I can
> see this output from my program :
>--------------------
>pSysIDBlockTail->idBlockSize : 132, addr : ffff0
>000ffff0 84 00 00 00 7C 5F 7C 5F 9F AA 55 AA 55 AA 55 AA ....|_|_..U.U.U.
>pSysIDBlockTail->idBlockSize : -1, addr : bfff0
>000bfff0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
>pSysIDBlockTail->idBlockSize : 539936478, addr : 7fff0
>0007fff0 DE C6 2E 20 9B 51 C2 52 B8 09 BA D2 B8 1A DC CB ... .Q.R........
>pSysIDBlockTail->idBlockSize : 539936478, addr : 3fff0
>0003fff0 DE C6 2E 20 9B 51 C2 52 B8 09 BA D2 B8 1A DC CB ... .Q.R........
>i1 : 0
>found at : fff7c
>
>mySysIDBlock: 0
>tableVersion : 2
>productID : 3840
>vendorID : 1
>timestamp : 20499
> 13 50 01 0f 08 25 08
>flashID : ffffbfd7
>flashType : 1
>flashSize : 128 1000h pages
>sectorSize : 4096 bytes
>numSectors : 128
>flashSpeed : 0 ns
>flash2ID : ffffbfd7
>flash2Type : 1
>flash2Size : 128 1000h pages
>sector2Size : 4096 bytes
>num2Sectors : 128
>flash2Speed : 0 ns
>ramID : 1
>ramSize : 128 1000h pages
>ramSpeed[ns] : 0 ns
>cpuID : 256
>crystalFreq[Hz] : 22118400 Hz
>macAddr[6] : 00 90 C2 C0 EC 67
>serialNumber :
>productName :
>reserved : 0
>idBlockSize : 132
>userBlockSize : 24444
>userBlockLoc : 24444
>marker : 55 AA 55 AA 55 AA
>--------------------
>
>a valid block is at 0x000ffff0
>there is also the correct MAC-address I've changed in write_idblock
>to the address the board was delivered with.
>but the table version is now 2! it was 4 before.
>
>I've tested the whole procedure with a cheaper RCM3110 module,
>all went OK.
>The last Messages I get from statusline after compile is :
>"Getting enabled options"
>"Closing connection"
>
> >>From: Bruce Isted <bisted@z...>
> >>Date: Thu Aug 21, 2003 11:22 am
> >>Subject: Re: [rabbit-semi] userblock usage RCM3000
>
> >>When you say ". . . SysIDBlock had a marker[5] ==
> >>0." are you referring to
> >>the SysIDBlock structure in SRAM that is initially
> >>copied from flash, or
> >>(one of) the ID Block(s) stored at the top of the
> >>first flash?
>
>it seems it was the SysIDBlock structure in SRAM.
>searching in flash the only one I found in [ffff0,bfff0,7fff0,3fff0]
>has 0xAA (see above).
>
> >>If the former, and not just when temporarily
> >>changed in the write_idblock.c
> >>utility itself, then there certainly seems to be a
> >>problem and I'm not sure
> >>how it would be caused, except by some errant code
> >>(bad pointer, runaway,
> >>etc.).
>
> >>If the latter, and if the ID/User Blocks are mirrored (ie: version 3 or 4
> >>ID Block), then it is normal for the "invalid" image's marker[5] == 0x00,
> >>while the "valid" image's marker[5] == 0xAA. The two images alternate
> >>between "valid" and "invalid" at each write to the User Block, with
> >>marker[5] being the only difference between the images.
>
> >>Recent versions of the write_idblock.c utility, when writing a version
> 3 or
> >>4 (mirrored) ID Block with User Block of nonzero size, actually write both
> >>"valid" and "invalid" copies of the ID Block. If writing a version 1 or 2
> >>(non-mirrored) ID Block or any version ID Block with no User Block
> >>(ie: zero size) then only one ID Block is written, at the very top of the
> >>first flash.
>
> >>Can you run any program at all, such as a standard Dynamic C sample that
> >>doesn't call writeUserBlock? If not, then something probably went wrong
> >>with the write_idblock.c utility.
>
>Not even Hello world is running.
>
> >>The only time I have seen anything similar is when I have accidentally
> >>written a non-RCM3200 board type into an RCM3200 (or derivative)
> target, or
> >>vice versa. These board types, when incorrectly written to a target's
> >>flash, mess up Dynamic C's BIOS because of the RCM3200's "unusual" memory
> >>device mapping.
>
> >>What happens if you let the RCM3000 sit (unpowered) to cool off for a
> >>while? Can you run any program then?
>No improvement. > >> - Bruce
>
> >> At 10:17 AM 8/21/03, you wrote:
> >> >Does writeUserBlock crash SysIdBlock on RCM3000 ?
> >> >
> >> >I wrote some bytes with writeUserBlock and read them back, OK.
> >> >Now my SysIdBlock had a marker[5] == 0x00.
> >> >I used write_idblock with MYBOARD defined to RCM3000 to
> correct this.
> >> >Now DC7.33P compiles but does not run any program.
> >> >I get "Timeout while waiting for response from target" after
> >> >compilation.
> >> >
> >> >How can I do a recovery of my RCM3000 board ?
> >> >
> >> >Thomas
>
>Thomas >
>To unsubscribe from this group, send an email to:
>rabbit-semi-unsubscribe@rabb... >
>">http://docs.yahoo.com/info/terms/
search for the ID Block version assignment in the body of the program code
and edit in the desired value. I notice that your program shows the User
Block size/offset is set to 24444 (decimal, or 0x5F7C), giving a total of a
24KB combined ID/User Block. This is another nonstandard value, I presume
your write_idblock.c utility has been modified to set this size?
What are the values of the MBxCRShadow registers when your program
runs? I'm going to assume that your program runs in RAM in the MB0CR+MB1CR
quadrants and and maps the RCM3000's first (/CS0) flash into the MB2CR
quadrant and its second (/CS2) flash into the MB3CR quadrant.
If this assumption is true, then your ID Block is located at the top of the
RCM3000's second flash, and the standard Dynamic C BIOS's flash init
library routines will not find it there, but they may be finding a mirrored
image of a version 3 or 4 ID Block located just below the top of flash
minus one of 8KB, 16KB, or 24KB.
It looks like you can run a program in RAM using the other (Softools?)
compiler, is that right? Can Dynamic C also load and run a program in
RAM? If so, I can send you directly (off-list) an updated version of the
write_idblock.c utility that will run in RAM to place ID Block(s) at the
top of the first flash.
- Bruce
At 03:08 AM 8/22/03, you wrote:
>With an other compiler (only reads from flash) I can
> see this output from my program :
>--------------------
>pSysIDBlockTail->idBlockSize : 132, addr : ffff0
>000ffff0 84 00 00 00 7C 5F 7C 5F 9F AA 55 AA 55 AA 55 AA ....|_|_..U.U.U.
>pSysIDBlockTail->idBlockSize : -1, addr : bfff0
>000bfff0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
>pSysIDBlockTail->idBlockSize : 539936478, addr : 7fff0
>0007fff0 DE C6 2E 20 9B 51 C2 52 B8 09 BA D2 B8 1A DC CB ... .Q.R........
>pSysIDBlockTail->idBlockSize : 539936478, addr : 3fff0
>0003fff0 DE C6 2E 20 9B 51 C2 52 B8 09 BA D2 B8 1A DC CB ... .Q.R........
>i1 : 0
>found at : fff7c
>
>mySysIDBlock: 0
>tableVersion : 2
>productID : 3840
>vendorID : 1
>timestamp : 20499
> 13 50 01 0f 08 25 08
>flashID : ffffbfd7
>flashType : 1
>flashSize : 128 1000h pages
>sectorSize : 4096 bytes
>numSectors : 128
>flashSpeed : 0 ns
>flash2ID : ffffbfd7
>flash2Type : 1
>flash2Size : 128 1000h pages
>sector2Size : 4096 bytes
>num2Sectors : 128
>flash2Speed : 0 ns
>ramID : 1
>ramSize : 128 1000h pages
>ramSpeed[ns] : 0 ns
>cpuID : 256
>crystalFreq[Hz] : 22118400 Hz
>macAddr[6] : 00 90 C2 C0 EC 67
>serialNumber :
>productName :
>reserved : 0
>idBlockSize : 132
>userBlockSize : 24444
>userBlockLoc : 24444
>marker : 55 AA 55 AA 55 AA
>--------------------
>
>a valid block is at 0x000ffff0
>there is also the correct MAC-address I've changed in write_idblock
>to the address the board was delivered with.
>but the table version is now 2! it was 4 before.
>
>I've tested the whole procedure with a cheaper RCM3110 module,
>all went OK.
>The last Messages I get from statusline after compile is :
>"Getting enabled options"
>"Closing connection"
>
> >>From: Bruce Isted <bisted@z...>
> >>Date: Thu Aug 21, 2003 11:22 am
> >>Subject: Re: [rabbit-semi] userblock usage RCM3000
>
> >>When you say ". . . SysIDBlock had a marker[5] ==
> >>0." are you referring to
> >>the SysIDBlock structure in SRAM that is initially
> >>copied from flash, or
> >>(one of) the ID Block(s) stored at the top of the
> >>first flash?
>
>it seems it was the SysIDBlock structure in SRAM.
>searching in flash the only one I found in [ffff0,bfff0,7fff0,3fff0]
>has 0xAA (see above).
>
> >>If the former, and not just when temporarily
> >>changed in the write_idblock.c
> >>utility itself, then there certainly seems to be a
> >>problem and I'm not sure
> >>how it would be caused, except by some errant code
> >>(bad pointer, runaway,
> >>etc.).
>
> >>If the latter, and if the ID/User Blocks are mirrored (ie: version 3 or 4
> >>ID Block), then it is normal for the "invalid" image's marker[5] == 0x00,
> >>while the "valid" image's marker[5] == 0xAA. The two images alternate
> >>between "valid" and "invalid" at each write to the User Block, with
> >>marker[5] being the only difference between the images.
>
> >>Recent versions of the write_idblock.c utility, when writing a version
> 3 or
> >>4 (mirrored) ID Block with User Block of nonzero size, actually write both
> >>"valid" and "invalid" copies of the ID Block. If writing a version 1 or 2
> >>(non-mirrored) ID Block or any version ID Block with no User Block
> >>(ie: zero size) then only one ID Block is written, at the very top of the
> >>first flash.
>
> >>Can you run any program at all, such as a standard Dynamic C sample that
> >>doesn't call writeUserBlock? If not, then something probably went wrong
> >>with the write_idblock.c utility.
>
>Not even Hello world is running.
>
> >>The only time I have seen anything similar is when I have accidentally
> >>written a non-RCM3200 board type into an RCM3200 (or derivative)
> target, or
> >>vice versa. These board types, when incorrectly written to a target's
> >>flash, mess up Dynamic C's BIOS because of the RCM3200's "unusual" memory
> >>device mapping.
>
> >>What happens if you let the RCM3000 sit (unpowered) to cool off for a
> >>while? Can you run any program then?
>No improvement. > >> - Bruce
>
> >> At 10:17 AM 8/21/03, you wrote:
> >> >Does writeUserBlock crash SysIdBlock on RCM3000 ?
> >> >
> >> >I wrote some bytes with writeUserBlock and read them back, OK.
> >> >Now my SysIdBlock had a marker[5] == 0x00.
> >> >I used write_idblock with MYBOARD defined to RCM3000 to
> correct this.
> >> >Now DC7.33P compiles but does not run any program.
> >> >I get "Timeout while waiting for response from target" after
> >> >compilation.
> >> >
> >> >How can I do a recovery of my RCM3000 board ?
> >> >
> >> >Thomas
>
>Thomas >
>To unsubscribe from this group, send an email to:
>rabbit-semi-unsubscribe@rabb... >
>">http://docs.yahoo.com/info/terms/
Reply by ●August 23, 20032003-08-23
> The write_idblock.c utility you used may be an older one, where you
have to
> search for the ID Block version assignment in the body of the program code
> and edit in the desired value. I notice that your program shows the User
> Block size/offset is set to 24444 (decimal, or 0x5F7C), giving a total of a
> 24KB combined ID/User Block. This is another nonstandard value, I presume
> your write_idblock.c utility has been modified to set this size?
write_idblock.c shows version 1.82. In the first comment I read
it will prompt if it finds a version 3 or 4.
The only modification I've done is to define MYBOARD as RCM3000.
This went OK with an RCM3100 (with MYBOARD as RCM3100 of course ;-).
Now I've found my mistake. I should have modified NUMUSER4KBLOCKS
and IDBLOCK_VERSION ! I assumed the program would set the factory defaults
of the specified boards.
> What are the values of the MBxCRShadow registers when your program
> runs? I'm going to assume that your program runs in RAM in the MB0CR+MB1CR
> quadrants and and maps the RCM3000's first (/CS0) flash into the MB2CR
> quadrant and its second (/CS2) flash into the MB3CR quadrant.
> If this assumption is true, then your ID Block is located at the top of the
> RCM3000's second flash, and the standard Dynamic C BIOS's flash init
> library routines will not find it there, but they may be finding a mirrored
> image of a version 3 or 4 ID Block located just below the top of flash
> minus one of 8KB, 16KB, or 24KB.
> It looks like you can run a program in RAM using the other (Softools?)
> compiler, is that right?
Thats right.
> Can Dynamic C also load and run a program in
> RAM?
Yes, I've overseen this mode.
> If so, I can send you directly (off-list) an updated version of the
> write_idblock.c utility that will run in RAM to place ID Block(s) at the
> top of the first flash.
That would be great. I've seen the "#ifndef _FLASH_" but I'am surprized about this.
> - Bruce
>snip<
Thanks
Thomas
> search for the ID Block version assignment in the body of the program code
> and edit in the desired value. I notice that your program shows the User
> Block size/offset is set to 24444 (decimal, or 0x5F7C), giving a total of a
> 24KB combined ID/User Block. This is another nonstandard value, I presume
> your write_idblock.c utility has been modified to set this size?
write_idblock.c shows version 1.82. In the first comment I read
it will prompt if it finds a version 3 or 4.
The only modification I've done is to define MYBOARD as RCM3000.
This went OK with an RCM3100 (with MYBOARD as RCM3100 of course ;-).
Now I've found my mistake. I should have modified NUMUSER4KBLOCKS
and IDBLOCK_VERSION ! I assumed the program would set the factory defaults
of the specified boards.
> What are the values of the MBxCRShadow registers when your program
> runs? I'm going to assume that your program runs in RAM in the MB0CR+MB1CR
> quadrants and and maps the RCM3000's first (/CS0) flash into the MB2CR
> quadrant and its second (/CS2) flash into the MB3CR quadrant.
> If this assumption is true, then your ID Block is located at the top of the
> RCM3000's second flash, and the standard Dynamic C BIOS's flash init
> library routines will not find it there, but they may be finding a mirrored
> image of a version 3 or 4 ID Block located just below the top of flash
> minus one of 8KB, 16KB, or 24KB.
> It looks like you can run a program in RAM using the other (Softools?)
> compiler, is that right?
Thats right.
> Can Dynamic C also load and run a program in
> RAM?
Yes, I've overseen this mode.
> If so, I can send you directly (off-list) an updated version of the
> write_idblock.c utility that will run in RAM to place ID Block(s) at the
> top of the first flash.
That would be great. I've seen the "#ifndef _FLASH_" but I'am surprized about this.
> - Bruce
>snip<
Thanks
Thomas
