B3000-ENET issues with the ReadStatusArea

I am writing some java code to talk to the B3000-ENET. I seem to be having an issue with using the ReadBlockRequest or ReadQuadletRequest at addresses beyond 0xffff_f030_007c.

  1. If I read data starting with 0xffff_f030_0000 and ending with 0xffff_f030_007c it works fine.
  2. If I try to read values beyond 0xffff_f030_007c, I get a nak error xe005. So I decided to merely read the last value in this region, the Firmware Version using a ReadQuadletRequest and it fails also.
  3. It is somewhat confusing that a ReadBlockRequest failure logs not the address of the failed memory location, but the starting address of the block.

// try to read the firmware revision using a ReadQuadletRequest
Sending…
000004400000fffff030024c
READ_QUADLET_RESPONSE rcode:5
Received…
00000460000050000000000000000000

// rcode of 5, read the error using a ReadQuadletRequest
Sending…
000004400000fffff030000c
READ_QUADLET_RESPONSE rcode:0
[B@3feba861
Received…
0000046000000000000000000000e005

// read the offending address via ReadQuadletRequest
Sending…
000004400000fffff0300014
READ_QUADLET_RESPONSE rcode:0
[B@5b480cf9
Received…
000004600000000000000000f030024c
LastError=e005 @ LastErrorAddress=f030024c

// try to read a0 bytes using a ReadBlockRequest
Sending…
000004500000fffff030000000a00000
READ_BLOCK_RESPONSE rcode:5
Received…
0000047000005000000000000000024c
// the above one was a bit confusing ending in 24c as if the firmware version was
// left hanging around in the B3000 from the last ReadQuadletRequest failure

// request the error code
Sending…
000004400000fffff030000c
READ_QUADLET_RESPONSE rcode:0
[B@723279cf
Received…
0000046000000000000000000000e005

// request the error address
Sending…
000004400000fffff0300014
READ_QUADLET_RESPONSE rcode:0
[B@10f87f48
Received…
000004600000000000000000f0300000
LastError=e005 @ LastErrorAddress=f0300000, dataLength=00a0
// this one was interesting because 0xffff_f030_0000 is not the address that fails
// but the first address requested

// do a powerup clear
Sending…
000004000000fffff038000000000001
WRITE_RESPONSE rcode:0
Received…
000004200000000000000000

// request the memory map version
Sending…
000004400000fffff0300000
READ_QUADLET_RESPONSE rcode:0
[B@5f184fc6
Received…
00000460000000000000000000000001

// request the firmware revision
Sending…
000004400000fffff030024c
READ_QUADLET_RESPONSE rcode:5
Received…
00000460000050000000000000000000

// request the error code
Sending…
000004400000fffff030000c
READ_QUADLET_RESPONSE rcode:0
[B@3feba861
Received…
0000046000000000000000000000e005

// request the error address
Sending…
000004400000fffff0300014
READ_QUADLET_RESPONSE rcode:0
[B@5b480cf9
Received…
000004600000000000000000f030024c
LastError=e005 @ LastErrorAddress=f030024c

// read 0x80 bytes starting at 0xffff_f030_0000
Sending…
000004500000fffff030000000800000
READ_BLOCK_RESPONSE rcode:0
[B@723279cf
Received…
0000047000000000000000000080024c0000000100000000000000000000e00500010000f030024c020002070200020000000098011407cf00100000000000a03d000dd8c0a80ae1ffffff00c0a8010100000000ae9ddf8f0000000000000001000000000000000000000bb801c8aa4701c97b1d00000bb8000000050003a98000000000000000000000000000000000

// it worked, and this is what I should see in the response packet
<fffff0300000:<4,“UI”,“Memory Map revision number”>>
<fffff0300004:<4,“UI”,“Powerup Clear flag”>>
<fffff0300008:<4,“UI”,“Busy flag”>>
<fffff030000c:<4,“I”,“Last error code”>>
<fffff0300010:<2,“UI”,“Transaction label of last command”>>
<fffff0300012:<2,“UI”,“SourceID of the last command”>>
<fffff0300014:<4,“UI”,“Address of last error”>>
<fffff0300018:<4,“UI”,“Loader revision”>>
<fffff030001c:<4,“IP”,“Firmware kernel revision”>>
<fffff0300020:<4,“UI”,“Unit type of the device”>>
<fffff0300024:<1,“UI”,“Hardware revision (Month)”>>
<fffff0300025:<1,“UI”,“Hardware revision (Day)”>>
<fffff0300026:<2,“UI”,“Hardware revision (Year)”>>
<fffff0300028:<4,“UI”,“Number of bytes of installed RAM”>>
<fffff030002c:<2,"-",“Reserved”>>
<fffff030002e:<6,“UI”,“ENET1 MAC addres”>>
<fffff0300034:<4,“IP”,“ENET1 TCP/IP address”>>
<fffff0300038:<4,“IP”,“ENET1 TCP/IP subnet mask”>>
<fffff030003c:<4,“IP”,“ENET1 TCP/IP default gatewa”>>
<fffff0300040:<4,“IP”,“ENET1 DNS server address”>>
<fffff0300044:<4,"-",“Reserved”>>
<fffff0300048:<4,“UI”,“Device sends BootP or DHCP on powerup”>>
<fffff030004c:<4,“B”,“Degrees are in degrees C (0) or degrees F (!=0)”>>
<fffff0300050:<50,"-",“Reserved”>>
<fffff0300054:<4,“UI”,“Watchdog time in milliseconds”>>
<fffff0300058:<4,“UI”,"">>
<fffff030005c:<4,“UI”,“TCP/IP minimum Response Timeout (msecs)”>>
<fffff0300060:<4,“UI”,“Digital scan counter”>>
<fffff0300064:<4,“UI”,“Initial RTO”>>
<fffff0300068:<4,“UI”,“TCP number of retries”>>
<fffff030006c:<4,“UI”,“TCP idle session timeout”>>
<fffff0300070:<4,“UI”,“Ethernet errors: late collisions”>>
<fffff0300074:<4,“UI”,“Ethernet errors: excessive collisions”>>
<fffff0300078:<4,“UI”,“Ethernet errors: other”>>
<fffff030007c:<4,“M”,"“Smart” modules present">>

// this is the contents of my Java Object[] resulting from the read
0x00000001
0x00000000
0x00000000
0x0000e005
0x0001
0x0000
0xf030024c
0x02000207
2.0.2.0
0x00000098
0x01
0x14
0x07cf
0x00100000
Reserved 2 bytes
00:a0:3d:00:0d:d8
192.168.10.225
255.255.255.0
192.168.1.1
0.0.0.0
Reserved 4 bytes
0x00000000
Reserved 50 bytes
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000

// and Jave prints out the array as follows
[1, 0, 0, 57349, 1, 0, -265289140, 33554951, 2.0.2.0, 152, 1, 20, 1999, 1048576, Reserved 2 bytes, 00:a0:3d:00:0d:d8, 192.168.10.225, 255.255.255.0, 192.168.1.1, 0.0.0.0, Reserved 4 bytes, 0, true, Reserved 50 bytes, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

If I run ioManager, the B3000-ENET shows status values from 0xffff_f030_0004 to 0xffff_f030_007c. The OptoMMP Protocol Guide table on p90 starts a table of values in the StatusAreaRead memory region. If the B3000_ENET status region stops at 0xffff_f030_007f, it is unclear from the guide. It is also unclear what data in a parameter unsupported by the B3000-ENET (ie: 0xffff_f030_0150, Multidrop Address) will require in a WriteBlockRequest, or return in a ReadBlockRequest.