Errors in DC9.21

What, rewriting the ID block according to compile settings ?!?!?
That's asking for trouble.

I never understood why all the Z-World modules and DynamicC require
an ID block. What's so important that needs to be stored in a
permanent 32kByte block of Flash.

Is it the flash size? ram size? cpu type? the cpu speed? the name of
the module? the vender ID ?? production date ??? or maybe the
version number of the ID block (so you can easily !?! restore it
when it gets erased)????

All this stuff can be easily detected at runtime without the need
for an 'eraseble ID block' wasting 32kByte of Flash space.

The only thing I can find which is usefull in the ID block, well
that's the MAC address. But why not add a small 15cent serial eeprom
on the modules to store the MAC address and some user data. All
other cpu modules use this system. And, its far more secure. These
eeprom are made to store user data.

Rudi
www.x-graph.be the next generation Rabbit SBC with Color TFT LCD

--- In rabbit-semi@rabb..., Scott Henion <shenion@s...>
wrote:
> At 07:22 PM 5/19/2005, you wrote:
>
> >Dynamic C 9.20 is the first release that "knows" about version 5
ID blocks,
> >and the version 5 ID block is only factory-installed on Z-World's
PowerCore
> >FLEX boards so far. Previous versions of the ID block are still
fully
> >supported by DC 9.2x.
> >
> >What issues are you seeing that make you think DC 9.2x somehow
expects the
> >version 5 ID block?
>
> I did not say it expects it, I said it creates one.
>
> > Do you have PowerCore FLEX boards with corrupted
> >version 5 ID blocks that need to be recovered or re-written? If
so,
> >Z-World Tech Support (or I) can supply a version of the
write_idblock.c
> >utility that will write a suitable version 5 ID block. If this
is the
> >case, how did the ID block corruption occur, and is it
reproducible?
>
> I don't have the powerflex board (although I was told I'd get one.)
>
> It is not just corruption. My DLM is written in Softools so it
needs to
> convert the ID block to ST format (in RAM so it knows how to skip
the
> user/id block areas.) Users reported problems with 8.x. This seems
to be a
> change in how the User block is handled. Before there was 2 user
blocks
> that share one ID block (v3). The new mirrored scheme makes 2 ID
blocks,
> one is marked invalid (v4?). The code was changed to search for
the ID
> block. Its fixed the problems.
>
> Then users reported additional problems on 3700/3300 boards when
using DC
> 9.x. It was found that the ID block format has suddenly changed. I
added
> decoding of the V5 ID block and that fixed the problems.
>
> >If it is the previously mentioned pilot BIOS issue that you ask
about, then
> >the problem is that the old pilot BIOS doesn't deliver the exact
> >information that the new DC 9.2x versions expect / require. This
problem
> >shows up when an older pilot.bin file is used by the new DC 9.2x,
as will
> >happen when a older DCP file is migrated to the new DC 9.2x
version.
>
> I was talking about a .c file with no project. I have seen garbage
code,
> TCP/IP stack bugs, DHCP issues, and the code size was too big for
projects
> that used to easily fit in flash. After trying several .c files
and seeing
> different bugs in the code generated, I gave up. I do little work
in DC, I
> use 7.33 as it is stable and supports all the modules (with a
little rework.)
>
> I would like a utility to generate a V5 ID block, although I could
write
> one. Might be useful for testing.
>
> BTW, I consider tha V5 ID block a bad idea. It is set up to be
rewritten
> according to compile settings. I consider the ID block should be
left
> alone. I have had users report it getting corrupted when using 9.x.
>
> <Scott>
>
> ------------
> | Scott G. Henion | shenion@s... |
> | Consultant | Stone Mountain, GA |
> | SHDesigns | PGP Key 0xE98DDC48 |
> |Rabbit Libs: http://www.shdesigns.org/rabbit/ |
> ------------ > --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.322 / Virus Database: 266.11.12 - Release Date:
5/17/2005


Start a New Thread

Since it's beat on DC week...

Run this code an look at the asm code for the two lines marked.
This clearly shows that DC32 was better than DCRabbit.
Softtools also creates very small code for the lines in question.

At the bottom it shows the asm code for several zworld compilers.
So on DC anyone using pointers gets a nice sized penalty
in code size and speed.
#memmap xmem

typedef struct _TEST
{
unsigned uVar1;
unsigned uVar2;
unsigned uVar3;
} TEST; int main(void)
{
static TEST Clean;
static TEST *pClean;

pClean = &Clean;

//LOOK AT THE ASM CODE FOR THESE TWO LINES
Clean.uVar1 = 1;
pClean->uVar1 = 1;
} /**
******************************
* Z180 Dynamic C 32
******************************
Clean.uVar1 = 1;
ff:e00f 210100 ld hl,0001
ff:e012 22E3D9 ld (D9E3),hl

pClean->uVar1 = 1;
ff:e016 2AE1D9 ld hl,(D9E1)
ff:e019 3601 ld (hl),01
ff:e01b 23 inc hl
ff:e01c 3600 ld (hl),00

******************************
* Rabbit Dynamic C 7.32
******************************
Clean.uVar1 = 1;
f9:e049 210100 ld hl,0001 6
f9:e04c 2206C3 ld (C306),hl 13
f9:e04f EF rst 28h 8

pClean->uVar1 = 1;
f9:e050 2A04C3 ld hl,(C304) 11
f9:e053 EB ex de,hl 2
f9:e054 2660 ld h,60 4
f9:e056 6A ld l,d 2
f9:e057 AF xor a 2
f9:e058 ED6C ldp hl,(hl) 10
f9:e05a FC rr hl 2
f9:e05b EB ex de,hl 2
f9:e05c DA62E0 jp c,E062 7
f9:e05f CD4C1E call bound_e 12
f9:e062 3601 ld (hl),01 7
f9:e064 23 inc hl 2
f9:e065 3600 ld (hl),00 7
f9:e067 EF rst 28h 8

******************************
* Rabbit Dynamic C 9.21
******************************
Clean.uVar1 = 1;
f8:eff5 ld hl,0x0001 6
f8:eff8 ld (0xC647),hl 13
f8:effb rst 0x28 8

pClean->uVar1 = 1;
f8:effc ld hl,(0xC645) 11
f8:efff ex de,hl 2
f8:f000 ld h,0x60 4
f8:f002 ld l,d 2
f8:f003 xor a 2
f8:f004 ldp hl,(hl) 10
f8:f006 rr hl 2
f8:f007 ex de,hl 2
f8:f008 jp c,0xF00E 7
f8:f00b call bound_e 12
f8:f00e ld (hl),0x01 7
f8:f010 inc hl 2
f8:f011 ld (hl),0x00 7
f8:f013 ljp 0x0xF9E017 10
f8:f017 rst 0x28 8
**/



Start a New Thread

Since it's beat on DC week...

Run this code an look at the asm code for the two lines marked.
This clearly shows that DC32 was better than DCRabbit.
Softtools also creates very small code for the lines in question.

At the bottom it shows the asm code for several zworld compilers.
So on DC anyone using pointers gets a nice sized penalty
in code size and speed.
#memmap xmem

typedef struct _TEST
{
unsigned uVar1;
unsigned uVar2;
unsigned uVar3;
} TEST;int main(void)
{
static TEST Clean;
static TEST *pClean;

pClean = &Clean;

      //LOOK AT THE ASM CODE FOR THESE TWO LINES
Clean.uVar1 = 1;
pClean->uVar1 = 1;
}/**
******************************
* Z180 Dynamic C 32
******************************
      Clean.uVar1 = 1;
ff:e00f 210100   ld    hl,0001
ff:e012 22E3D9   ld    (D9E3),hl

      pClean->uVar1 = 1;
ff:e016 2AE1D9   ld    hl,(D9E1)
ff:e019 3601     ld    (hl),01
ff:e01b 23       inc   hl
ff:e01c 3600     ld    (hl),00

******************************
* Rabbit Dynamic C 7.32
******************************
      Clean.uVar1 = 1;
f9:e049 210100   ld    hl,0001             6
f9:e04c 2206C3   ld    (C306),hl          13
f9:e04f EF       rst   28h                 8

      pClean->uVar1 = 1;
f9:e050 2A04C3   ld    hl,(C304)          11
f9:e053 EB       ex    de,hl               2
f9:e054 2660     ld    h,60                4
f9:e056 6A       ld    l,d                 2
f9:e057 AF       xor   a                   2
f9:e058 ED6C     ldp   hl,(hl)            10
f9:e05a FC       rr    hl                  2
f9:e05b EB       ex    de,hl               2
f9:e05c DA62E0   jp    c,E062              7
f9:e05f CD4C1E   call  bound_e            12
f9:e062 3601     ld    (hl),01             7
f9:e064 23       inc   hl                  2
f9:e065 3600     ld    (hl),00             7
f9:e067 EF       rst   28h                 8

******************************
* Rabbit Dynamic C 9.21
******************************
Clean.uVar1 = 1;
f8:eff5   ld     hl,0x0001      6
f8:eff8   ld     (0xC647),hl    13
f8:effb   rst    0x28           8

pClean->uVar1 = 1;
f8:effc   ld     hl,(0xC645)    11
f8:efff   ex     de,hl          2
f8:f000   ld     h,0x60         4
f8:f002   ld     l,d            2
f8:f003   xor    a              2
f8:f004   ldp    hl,(hl)        10
f8:f006   rr     hl             2
f8:f007   ex     de,hl          2
f8:f008   jp     c,0xF00E       7
f8:f00b   call   bound_e        12
f8:f00e   ld     (hl),0x01      7
f8:f010   inc    hl             2
f8:f011   ld     (hl),0x00      7
f8:f013   ljp    0x0xF9E017     10
f8:f017   rst    0x28           8
**/

---

Check email on your mobile phone.

Start a New Thread

--- In rabbit-semi@rabb..., Larry Kilmer <lkkilmer@y...>
wrote:
> Not defending DC cause the Rabbit code is UGLY but it seems the
Rabbit compilers were producing code with debug turned on and the
Z180 maybe didn't. Possibly how default settings for the compilers
are set. Interesting test anyway.
>
If this reply shows up twice, sorry...Having technical issues lately.

The reason for such ugly code is because of pointer and array
checking. Since you are assigning to a pointer, it wants to make
certain that pointer is a legitimate pointer.

I don't know if Softools provides run-time checking of arrays; if so,
it probably puts in some not-so-clean code, too.

I never purchased DC32, but I do have the 16-bit Z180 Dynamic C and
still program a few products that I haven't retrofitted to Rabbit
products. I assume DC32 also has the ability to do array and bounds
checking.

Here is the Z-180 code created with its array and bounds checking on:

2443 21F9DC ld hl,DCF9
2446 22F7DC ld (DCF7),hl
2449 EF rst 28h
244a 210100 ld hl,0001
244d 22F9DC ld (DCF9),hl
2450 EF rst 28h
2451 2AF7DC ld hl,(DCF7)
2454 1621 ld d,21
2456 5C ld e,h
2457 1A ld a,(de)
2458 B7 or a
2459 F4D702 call p,bound.e
245c 3601 ld (hl),01
245e 23 inc hl
245f 3600 ld (hl),00
2461 EF rst 28h


Start a New Thread

Robert,
You are correct I was using DC9.10 and pointer checking was on.
I normally have these turned off, since I compile mostly to .bin.
using projects.

I Checked Code again in DC9.10 with all debug off, MUCH BETTER.
Alot better than I thought. I just dont trust most of the debug
stuff, I've had weird things happen with tracing and some of the
other new stuff turned on.

Thanks Robert! for waking me up! Clean.uVar1 = 1;
f8:eef5 210100 ld hl,0x0001 6
f8:eef8 2266C6 ld (0xC666),hl 13
f8:eefb EF rst 0x28 8
pClean->uVar1 = 1;
f8:eefc 2A64C6 ld hl,(0xC664) 11
f8:eeff 3601 ld (hl),0x01 7
f8:ef01 23 inc hl 2
f8:ef02 3600 ld (hl),0x00 7
f8:ef04 EF rst 0x28 8



Start a New Thread

Please see my answers / comments / questions interspersed in the
quoted email below.

- Bruce

--- In rabbit-semi@rabb..., Scott Henion <shenion@s...>
wrote:
> At 07:22 PM 5/19/2005, you wrote:
>
> >Dynamic C 9.20 is the first release that "knows" about version 5
ID blocks,
> >and the version 5 ID block is only factory-installed on Z-World's
PowerCore
> >FLEX boards so far. Previous versions of the ID block are still
fully
> >supported by DC 9.2x.
> >
> >What issues are you seeing that make you think DC 9.2x somehow
expects the
> >version 5 ID block?
>
> I did not say it expects it, I said it creates one.

To the best of my knowledge, currently the only Z-World / Rabbit
Semiconductor board shipped with a version 5 ID block is the
PowerCore FLEX. How are you finding that DC 9.21 is creating a
version 5 ID block? What program(s) are you running when this
happens?

>
> > Do you have PowerCore FLEX boards with corrupted
> >version 5 ID blocks that need to be recovered or re-written? If
so,
> >Z-World Tech Support (or I) can supply a version of the
write_idblock.c
> >utility that will write a suitable version 5 ID block. If this
is the
> >case, how did the ID block corruption occur, and is it
reproducible?
>
> I don't have the powerflex board (although I was told I'd get one.)

Please check on this again with Sales or Tech Support or whoever you
spoke with before.

>
> It is not just corruption. My DLM is written in Softools so it
needs to
> convert the ID block to ST format (in RAM so it knows how to skip
the
> user/id block areas.) Users reported problems with 8.x. This seems
to be a
> change in how the User block is handled. Before there was 2 user
blocks
> that share one ID block (v3). The new mirrored scheme makes 2 ID
blocks,
> one is marked invalid (v4?). The code was changed to search for
the ID
> block. Its fixed the problems.

The V. 2 ID block has a single (non-mirrored) User block that it is
combined with. By "combined" I mean that the ID block and the User
block (if present) may share a flash sector.

The V. 3 and 4 ID blocks are very similar to each other, differing
only in the number of their elements actually populated with data.
No ZW / RS production board was ever shipped with a V. 3 ID block,
AFAIK. The V. 3 and 4 ID block is also combined with the User
block, and both are mirrored for robustness.

The V. 5 ID block on the PowerCore FLEX has additional information
in and around it, but is also a combined + mirrored type similar to
the V. 3 and 4 ID blocks.

>
> Then users reported additional problems on 3700/3300 boards when
using DC
> 9.x. It was found that the ID block format has suddenly changed. I
added
> decoding of the V5 ID block and that fixed the problems.

Again, no RCM33xx or RCM37xx, or any board other than the PowerCore
FLEX should have a V. 5 ID block on it. Do you know how this is
happening?

>
> >If it is the previously mentioned pilot BIOS issue that you ask
about, then
> >the problem is that the old pilot BIOS doesn't deliver the exact
> >information that the new DC 9.2x versions expect / require. This
problem
> >shows up when an older pilot.bin file is used by the new DC 9.2x,
as will
> >happen when a older DCP file is migrated to the new DC 9.2x
version.
>
> I was talking about a .c file with no project. I have seen garbage
code,
> TCP/IP stack bugs, DHCP issues, and the code size was too big for
projects
> that used to easily fit in flash. After trying several .c files
and seeing
> different bugs in the code generated, I gave up. I do little work
in DC, I
> use 7.33 as it is stable and supports all the modules (with a
little rework.)
>
> I would like a utility to generate a V5 ID block, although I could
write
> one. Might be useful for testing.

Z-World's Tech Support (or I) can supply an updated (ugly) version
of the write_idblock.c utility that will write a version 5 ID block,
given that it is compiled using DC 9.2x. You could probably port it
to Softools quite easily, although you'd also need to port at least
IDBLOCK.LIB and FLASHWR.LIB along with it.

>
> BTW, I consider tha V5 ID block a bad idea. It is set up to be
rewritten
> according to compile settings. I consider the ID block should be
left
> alone. I have had users report it getting corrupted when using 9.x.
>

No version of the ID block should be rewritten, except in rare
instances. For example, where an application requires a different
User block size, or similar reason. What do you mean when you say
that compile settings are responsible for rewriting the V. 5 ID
block?

In the past, we have changed the version of ID block that is factory
installed on a particular product, and found it to be a mistake. We
try very hard not to repeat this mistake. Are you seeing that it
has re-occurred on ZW / RS "factory-fresh" boards?

> <Scott>
>
> ------------
> | Scott G. Henion | shenion@s... |
> | Consultant | Stone Mountain, GA |
> | SHDesigns | PGP Key 0xE98DDC48 |
> |Rabbit Libs: http://www.shdesigns.org/rabbit/ |
> ------------ > --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.322 / Virus Database: 266.11.12 - Release Date:
5/17/2005


Start a New Thread

At 12:29 PM 5/20/2005, you wrote:

>To the best of my knowledge, currently the only Z-World / Rabbit
>Semiconductor board shipped with a version 5 ID block is the
>PowerCore FLEX. How are you finding that DC 9.21 is creating a
>version 5 ID block? What program(s) are you running when this
>happens?

I'm not running anything. Just users reported problems on RCM3200/3700
until I added V5 user block support.

>Again, no RCM33xx or RCM37xx, or any board other than the PowerCore
>FLEX should have a V. 5 ID block on it. Do you know how this is
>happening?

No. I don't see anything in the libs that does it.

>Z-World's Tech Support (or I) can supply an updated (ugly) version
>of the write_idblock.c utility that will write a version 5 ID block,
>given that it is compiled using DC 9.2x. You could probably port it
>to Softools quite easily, although you'd also need to port at least
>IDBLOCK.LIB and FLASHWR.LIB along with it.

I already can read a V5 user block, Softools does it also. If i need to
force a V5 ID block I'll write a Softools utility as it would be simpler.

> >
> > BTW, I consider tha V5 ID block a bad idea. It is set up to be
>rewritten
> > according to compile settings. I consider the ID block should be
>left
> > alone. I have had users report it getting corrupted when using 9.x.
> >
>
>No version of the ID block should be rewritten, except in rare
>instances. For example, where an application requires a different
>User block size, or similar reason. What do you mean when you say
>that compile settings are responsible for rewriting the V. 5 ID
>block?

It looks by the code that #defines are being migrated to the new ID block.
Looking closer I see there is no way to add a macro to the ID block.

>In the past, we have changed the version of ID block that is factory
>installed on a particular product, and found it to be a mistake. We
>try very hard not to repeat this mistake. Are you seeing that it
>has re-occurred on ZW / RS "factory-fresh" boards?

The V5 ID block still looks like a bad idea. There is a lot of code added
to the bioslib _even for boards that will never use a V5 ID block_.

uint32 macrosLoc; // Start of the macro table for additional board
// configuration options.
uint32 driversLoc; // offset to preloaded drivers start from ID block
// start (positive is below ID block)
uint32 ioDescLoc; // offset to I/O descriptions start from ID block
// start (positive is below ID block)
uint32 ioPermLoc; // offset to User mode I/O permissions start from ID
// block start (positive is below ID block)

Here's pointers to flash data stored outside the ID/User block? This makes
every 3rd party have to follow ZW's whims on what is stored there. I would
think even ZW's DLM would overwrite it as it is now.

This type of stuff has caused me to increase the cost of my libs (ST
unchanged.) I know Softools is wasting a lot of time keeping up with this
stuff. I bet Rudy is getting annoyed with these arbitrary changes.

So the powerflex can have one of two NICs. Why not have the info in the
board ID. Then it can be compiled for that board type without all the extra
code for the other device and wasted code to check for different ID blocks.
I would not want ZW to be able to change the NIC from asix to SMSC and
still keep the same board model #. If you have to order a different part #
to use the other NIC, it should use a different board ID to identify it.
Otherwise, any targetless compile to .bin would need to include code for
all possible configurations. Again a waste of code.

BTW, why is the powerflex 1 wait state? Seems silly to run ~50mhz then slow
it down to an effective speed of 37mHz by adding 1ws even when running in
fast RAM. The only advantage seems to be more flexibility with baud rates
and 1meg Flash (although I see no support for using it in DC. ST has
support coming in the next release ;) .)

<Scott>

------
| Scott G. Henion| shenion@shen... |
| Consultant | Stone Mountain, GA |
| SHDesigns | PGP Key 0xE98DDC48 |
| http://www.shdesigns.org |
------
today's fortune
Data, n.:
Computerspeak for "information". Properly pronounced
the way Bostonians pronounce the word for a female child. --
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 266.11.14 - Release Date: 5/20/2005


Start a New Thread

Scott Henion escribi

>[snip]
>The V5 ID block still looks like a bad idea. There is a lot of code added
>to the bioslib _even for boards that will never use a V5 ID block_. >
You mind theres not condiyional compiler directives in the bios to
eliminate that code? Any code compiled with V 9.21 will have that code ,
thas i never will use?
That explain the more than 10k diff in the code, from version 8.5 to
9.21. :(

German .

Start a New Thread

Start a New Thread

I'm sorry that you had trouble with this also.  We are looking at ways to make migration of project files less troublesome, but have not come to any conclusions yet.  It is obviously not possible to anticipate every problem and resolve it automatically, but I believe that we should try to make potential trouble spots easier to identify.  On the other hand, it may be that supporting migration of project files across compiler releases is just more trouble than it's worth, and DC just needs to recognize and reject the old DCP file.

At 04:28 PM 5/22/2005, you wrote:

Bruce,
 
In regards to the migration of project files between DC versions, we recently discovered the hard way that they are not compatible when moving from 8.61 to 9.10.
 
DC was whinging about a coldloader issue, and after wasting some time discovered that the project file was originally created in 8.61 (and the coldloader and pilot paths were pointing to the 8.61 directory which was not installed on this particular PC). What was annoying is that:
a)       The coldloader and pilot information is not present to the user in the project settings screen (both PCs had identical settings) so the problem was only discovered once the project file was opened in a text editor.
b)       There was no warning message about project file version mismatches.
 
I can understand that project files could be incompatible between DC versions, but you seem to suggest its not necessarily a bad thing to migrate a project file?
 
Regards,
Nathan
 
 
-----Original Message-----
From: r...@yahoogroups.com [mailto:r...@yahoogroups.com] On Behalf Of Bruce Isted
Sent: Friday, 20 May 2005 8:35 AM
To: r...@yahoogroups.com
Subject: Re: [rabbit-semi] Errors in DC9.21
 
Sorry for the inconvenience, we have just recently identified this annoying
problem and found a work around.

If you're carrying forward a Dynamic C project (DCP) file from DC 8.51 to
9.21, you will encounter problems due to a change in the pilot BIOS that is
necessary to support the PowerCore FLEX's version 5 ID block.

This problem can be resolved by making a copy of your project file (maybe
append "921" at the end of the file name) and then editing (with Dynamic C
closed) the pathlists for the coldload.bin and pilot.bin files to suit your
DC 9.21 installation.

  - Bruce

At 09:58 AM 5/19/2005, you wrote:
>I come from DC 8.51 and trying DC 9.21.
>
>I get that errors when i try to compile to flash or trying to resest the
>board.
>
>line    1 : WARNING ERROR        : No parameters found for flash id
>received from pilot bios -  using default parameters.
>line   33 : WARNING BOARDTYPES.LIB   : No ID Block found on the target;
>defining _BOARD_TYPE_ to be a BL1810.
>
>I see in the downlaod dialog a bad id for my boards:
>
>RCM2100 : Board 0x0314
>RCM2110 : Board 0x0414
>
>The same boards work excelent with DC 8.51 , same machine, all the same
>except DC version. I switch from one version to another and stop working.
>Im using a USB to serial adapter from Keyspan (19W) and ever work
>excellent at 4xx KBPS.
>Any idea?
>
>German.
>
>
>
>Yahoo! Groups Links
>
>
>
>

---

Yahoo! Groups Links To

Start a New Thread