readUserBlock error RCM4310, stand-alone versus debugger

this might not be particular to the RCM4310, but I never had this
problem before when working on the RCM3000:

readUserBlock throws an error code -2 (No valid ID block found) when
running in stand-alone mode on the RCM4310, but returns seemingly
fine when running inside the debugger

new documentation on readUserBlock indicates needing to check for
contention with the serial flash ("A POSITIVE RETURN VALUE INDICATES
THAT THE SPI PORT OF THE SERIAL FLASH IS IN USE BY ANOTHER DEVICE")
which I do.

any help? when the function fails and returns -2 it fails immediately

I can't see anything in the RCM4300 documentation to indicate staying
away from this section of user memory

char ub[300];
int i, r;
i=0;
do {
r= readUserBlock( (void *) ub, 0, 300);
if (r>0) Delay(10);
i++;
} while (r>0);
the user block on my module seems to be fine since I can run the
userblock_info.c demo (in the debugger, haven't tried it standalone)

SysIDBlock.userBlockSize=0 when I run in stand-alone, but 8196 bytes
when running in the debugger

Start a New Thread

when running in standalone mode on RCM4310, readUserBlock() fails
with its call to GetUserBlockInfo(&uBI), does anyone understand why
this would fail without having to debug further into the library
routines?

here's the internal return on userBlockInfo in the debugging mode:

MyReadUserBlock: GetUserBlockInfo(&uBI) returns
addrA = 1056264
addrB = 1047816
blockSize = 8186
topAddr = 1081344
blockAvalid= 1
MyReadUserBlock: physaddr= 7688l

read RCM user block, ret= 0 (0=ok, 1 tries)
and here's the internal return on userBlockInfo in standalone mode:

MyReadUserBlock: GetUserBlockInfo(&uBI) returns
addrA = 1056264
addrB = 1047816
blockSize = 0
topAddr = 1081344
blockAvalid= 0
MyReadUserBlock: failed CheckUserBlockRange()

read user block, ret= -2 (0=ok, 1 tries)
is there some compiler directive or preprocessor define that needs to
be set?
Start a New Thread

of course, I formatted physaddr wrong (%ul), but that's not the issue:
physaddr= 1056264, when called readUserBlock( (void *) ub, 0, 200)

> MyReadUserBlock: physaddr= 7688l

Start a New Thread

On Apr 17, 2008, at 10:09 AM, ajf_alex wrote:
> of course, I formatted physaddr wrong (%ul), but that's not the issue:
> physaddr= 1056264, when called readUserBlock( (void *) ub, 0, 200)
>
> > MyReadUserBlock: physaddr= 7688l
The RCM4300 uses a serial flash instead of a parallel flash for
program and UserBlock storage. You don't really get a physical
address that you can read the UserBlock from.

There is a chance that when running from RAM in the debugger, there's
a copy of the UserBlock stored in RAM, but I'm not positive on that.

If you use the readUserBlock and writeUserBlock functions, does it
store and recover the data you write? If you need to write data from
multiple locations, take a look at writeUserBlockArray.

-Tom Start a New Thread

It turns out this problem with the RCM4310 can be corrected by a
small patch to the Lib/Rabbit4000/BIOLIB/StdBios.c file provided by
Rabbit/Digi. I'm still having some problems with read/write UserBlock
and memory corruption on the RCM4310 when called from inside indexed
cofunctions, and at other times, and am trying to work something out
with Rabbit engineering support to get a good test case to pinpoint
the trouble. I'm hoping to get this all fixed, since I find the
userBlock to be useful for storing calibration constants. Even though
I could store them on the SD card, the SD card might be replaced in
operation, so userBlock is the best place for storing this
information.Alex

--- In r..., Tom Collins wrote:
>
> On Apr 17, 2008, at 10:09 AM, ajf_alex wrote:
> > of course, I formatted physaddr wrong (%ul), but that's not the
issue:
> > physaddr= 1056264, when called readUserBlock( (void *) ub, 0, 200)
> >
> > > MyReadUserBlock: physaddr= 7688l
> The RCM4300 uses a serial flash instead of a parallel flash for
> program and UserBlock storage. You don't really get a physical
> address that you can read the UserBlock from.
>
> There is a chance that when running from RAM in the debugger,
there's
> a copy of the UserBlock stored in RAM, but I'm not positive on that.
>
> If you use the readUserBlock and writeUserBlock functions, does it
> store and recover the data you write? If you need to write data
from
> multiple locations, take a look at writeUserBlockArray.
>
> -Tom
>

Start a New Thread