[FRAM71] Pre-Production Batch

[Hans Brueggemann]

(02-27-2015 05:20 AM)Dave Frederickson Wrote:  The FRAM71 manual has some important notes at the end of the Memory Configuration chapter. Note 6 states that memory for ROM images should be configured the same as the physical module. 32k ROM's, like the Math ROM, are comprised of 2-16k ROM's. That means that a FRAM71 Chip shouldn't be configured as a single 32k ROM.

This is an ambiguity in the manual. the recommendation to configure ROM images the same way as their physical counterpart is given for only one reason: avoid the diagnostic module throwing an error on 32KB images where it expects them to be 2 x16 kB images. As J-F pointed out, the diagnostic module is looking at 16kB checksums and hence doesn't properly recognize 32KB chips w/o adjusting the checksums.
Practically, if the user doesn't care about the diagnostic module giving checksum errors on ROM images, it makes more sense to configure the images into single chips of 32K, because FRAM is segmented into 32K memory blocks. More so, as two (=64K) blocks of precious FRAM space get used up when configuring a ROM image to 2 x 16K.

(02-27-2015 05:20 AM)Dave Frederickson Wrote:  Firmware v430 sports a new feature allowing the same FRAM address space to be assigned to multiple chips. It should be possible to configure one 32k block of FRAM as two 16k ROM's, in accordance with Note 6.

FRAM space is segmented into 32K blocks, which can't be changed. when trying to configure "24A4", HP-71B will indeed detect one RAM module consisting of two chips, each with a size of 16K, and SHOWPORT reports it as 5 32768 0. However, FRAM71's MMU is mapping the first chip ("24") to F_0x40000, and the second one ("A4") on top of it, i.e., also at F_0x40000. FRAM71 can't assign multiple chips to the same F-Block in a _consecutive_ manner, but only on top of each other. that means that a chip which is configured to a particular F-Block will be mirrored by all chips that are configured to the same F-Block.
Note that firmware V42x.has an automatic block-assignment feature that prevents this behavior.

(02-27-2015 05:20 AM)Dave Frederickson Wrote:  Port(5) didn't get freed.

With said "24A4" configuration, the memory configuration routine of the HP-71B will execute FREEPORT(5) on the first chip by writing the magic number into H_0x30000, which is, for our example "24A4", = F_0x40000 in FRAM. Then, FREEPORT will clear the newly acquired memory, thus overwriting the magic number in chip_0 while seemingly erasing chip_1. therefore, SHOWPORT will not find any FREEd port.

(02-27-2015 05:20 AM)Dave Frederickson Wrote:  Two ports freed with one command. Wasn't expecting that behavior.

Here, "A4A4" vectors two single-chip modules to the same F-Block.the FREEPORT(5) magic number gets mirrored into port(5.01) and consequently SHOWPORT finds two FREEPORTs.

(02-27-2015 05:20 AM)Dave Frederickson Wrote:  Now the port isn't being detected.

FRAM71's best feature is also its worst: It doesn't forget anything inside disabled/unused F-Blocks unless "explicitly ordered" to do so. FREEPORT magic numbers get easily forgotten when changing memory configuration but may unexpectedly come back to life once you revive a previously disabled F-Block. typical symptoms are less-than-expected memory reported by MEM, as well as ports(x.xx) that can neither be FREEd, nor CLAIMed (guess how i know...)

To get portions of FRAM71's memory back to a known state, erase all magic numbers that may still be hiding in the F-Blocks that you are going to use:
1) configure two 32kByte modules at F_0x40000: "94950....0"
2) OFF
3) Close jumper CN2:2 "DIS_OUT_wh_CONF"
4) [ON]/[/],3 --> MEMORY LOST
5) OFF.
6) open jumper CN2:2 "DIS_OUT_wh_CONF"
7) ON
8) MEM --> 82 kByte
Then, configure the chips a desired:
1) "24A50...0" for one 32K RAM module consisting of two 16K chips, located at F_0x40000 and F_0x50000
2) OFF / ON
3) FREEPORT(5)
4)...


Hans