[FRAM71] Pre-Production Batch

[Dave Frederickson]

Since this is just a warning I've simply ignored it and never bricked my FRAM71, however there may some subtle side effects that I'm unaware of.

I also tried updating the Program DataBase (PDB) file as follows:

1. Without the FRAM71 connected to the FlashPro4, open FlashPro and the project file, then open the Modify PDB window.

2. The Modify PDB window displays:

Click to zoom


That's exactly where the ufc file is so I don't know why it's showing a warning. Click Import, ...

3. Click Next. This window shows a warning, too.



Check all of the Program page boxes and click Save PDB.

4. FlashPro probably reported a warning message about the programmer not matching, as expected. Rescan for programmers and resave the project file. Close and reopen the project and all the warnings are gone.

5. Don't forget to disconnect the programmer from the USB cable before connecting it to the FRAM71.

Let us know how it goes.

Dave

[Hans Brueggemann]

Thanks Dave, great write-up!
i put a link to your post into post #1 so it won't get lost.

hans

[cruff]

Tonight I was able to successfully update my FRAM71 to the latest firmware using a Microsemi FlashPro5 and FlashProExpress 11.5 SP2 running under CentOS 6.6 Linux. At first I tried jumpering VPUMP and VJTAG at my adapter cable, but it kept complaining about lack of VJTAG. Couldn't tell if the FlashPro5 was providing 3.3V with the multimeter, so I fell back to jumpering R10 and R11, after which it programmed successfully. I did get the message about using the external VPUMP instead of the FlashPro5 provided one, but that was safe to ignore.

EDIT: I also needed a variant of the project from Hans, known as a "chain mode project". Apparently FlashProExpress doesn't handle a non-chain mode project.

[Dave Frederickson]

(06-13-2015 01:39 AM)cruff Wrote:  Tonight I was able to successfully update my FRAM71 to the latest firmware using a Microsemi FlashPro5 and FlashProExpress 11.5 SP2 running under CentOS 6.6 Linux. At first I tried jumpering VPUMP and VJTAG at my adapter cable, but it kept complaining about lack of VJTAG. Couldn't tell if the FlashPro5 was providing 3.3V with the multimeter, so I fell back to jumpering R10 and R11, after which it programmed successfully. I did get the message about using the external VPUMP instead of the FlashPro5 provided one, but that was safe to ignore.

EDIT: I also needed a variant of the project from Hans, known as a "chain mode project". Apparently FlashProExpress doesn't handle a non-chain mode project.

Sounds like your cable is missing a connection between pin 7 on the programmer (VPUMP) to pin 5 on the FRAM71 (VJTAG).

I don't think FlashProExpress will work with a single device. FlashProExpress is intended to be used for multiple, daisy-chained (chain-mode) devices. Since the FlashPro5 can only provide VPUMP for one device, the software might not work in this configuration.

If you remove R10 the warning about external VPUMP will go away as the FlashPro5 is providing VPUMP. Another way is to disable VPUMP in the FlashPro Programmer Settings.

Dave

[cruff]

(06-13-2015 08:07 AM)Dave Frederickson Wrote:  Sounds like your cable is missing a connection between pin 7 on the programmer (VPUMP) to pin 5 on the FRAM71 (VJTAG).

I did a continuity test and the cable appears to be correct. Since I was able to update the FRAM71, I'm not going to tempt fate by trying to figure out what exactly was going on.

[Hans Brueggemann]

i've tested a FlashPro 5 programmer and had quite a hard time to get it properly to work. as it came out, the programmer does not enable VPUMP unless VJTAG is present. so, on my particular specimen, connecting VJTAG and VPUMP didn't do the trick. because FRAM71 has a dedicated pin for supplying 3.3V to a future piggy-back peripheral, i opted for a kind of pigtail extension on the programmer cable to deal with the VJTAG supply. works like a charm, especially "view device status" works without giving an ICS error.
seems that at least some of you guys got the programmer to work with less hassle, but to save the rest of us from more b,s&t i did a short write-up here


hans

[cruff]

(06-15-2015 06:20 PM)Hans Brueggemann Wrote:  i've tested a FlashPro 5 programmer and had quite a hard time to get it properly to work. as it came out, the programmer does not enable VPUMP unless VJTAG is present.

That certainly explains the behavior I observed. From my experience with the pain jumping the small SMT layout of the R10 and R11 jumper positions, it looks like Hans' cable would be an easier solution unless you have tiny hands. :-)

[Hans Brueggemann]

i've added a graphic representation of the FlashPro cable connection to FRAM71 in the FlashPro_Cable document (see post #1) in order clarify usage of the cable.

hans

[Michael Lopez]

Great Hans - additional diagram makes it very clear.

Thanks,

Michael

[Dave Frederickson]

I just noticed that the LED blinks when the 71 is turned on or an INIT is executed. The number of blinks seems to be dependent on the number of modules installed, either physical or in FRAM. What is the LED indicating?

Dave

[Hans Brueggemann]

the red LED's purpose somehow went "out of control" during the development process of the firmware and became more and more a handy debugging tool for me. That's why I never fully documented its function in the manual.
1) when inserting the FRAM71 into the HP-71B and then applying power, the internal states of the module are undefined, which sometimes leads to the LED being ON. (all FW versions)
2) pressing [ON] on the calculator brings FRAM71 into a known state, so it will switch the LED off. This is a good sign, because FRAM71 has accepted and properly decoded a RESET command. (all FW versions. it’s indeed a command, not just a reset pin being toggled)
3) Once FRAM71 is fully operational, switching your HP-71B off and then on again will result in a very brief and dim flash of the LED to indicate that the configuration registers of the “chips” are readied to accept data from HP-71B’s memory configuration routine. (FW 51x only. note that your HP-71B does a full memory configuration exercise on each start-up)
4) The LED will stay on as long as you have the write-protect status removed from the SYSRAM area, even if the HP-71B is off. (all FW versions)
5) The LED will blink when transmitting data over FRAM71’s UART (all FW versions)

6) FRAM71 Diagnostics that you can perform to verify proper operation:

1. Basically, 2), 3) tell you that FRAM71 is properly inserted into the cardreader bay, and that all data lines can be interpreted. sounds banal, but I had 2 FRAM71 buyers who had never used the cardreader port, so the contact pins had accumulated some foreign matter which prevented FRAM71 from properly communicating with the HP-71B. at that time, FRAM71 firmware didn’t have this diagnostic feature, which led to a mild panic among all parties ;o) If you ever face this problem, use isopropyl (isopropanol) and a cotton swab to clean the contacts. _DO NOT_ use WD40 or denaturated alcohol.
2. With the shipped configuration, you can do a POKE and PEEK$ to address 0x30000. If PEEK$ result matches POKE, then you have verified functionality of the CMD-decoder, the bidirectional RAM-interface, the PC/DP counters, the ID-register multiplexer, the STR-phase-shifter, and the MMU.
3. The LED can be tested by installing / removing CN2:4 (read the fine manual)
   

hans

[rprosperi]

(07-16-2015 11:47 AM)Hans Brueggemann Wrote:  the red LED's purpose somehow went "out of control" during the development process of the firmware and became more and more a handy debugging tool for me. That's why I never fully documented its function in the manual.
1) when inserting the FRAM71 into the HP-71B and then applying power, the internal states of the module are undefined, which sometimes leads to the LED being ON. (all FW versions)
2) pressing [ON] on the calculator brings FRAM71 into a known state, so it will switch the LED off. This is a good sign, because FRAM71 has accepted and properly decoded a RESET command. (all FW versions. it’s indeed a command, not just a reset pin being toggled)
3) Once FRAM71 is fully operational, switching your HP-71B off and then on again will result in a very brief and dim flash of the LED to indicate that the configuration registers of the “chips” are readied to accept data from HP-71B’s memory configuration routine. (FW 51x only. note that your HP-71B does a full memory configuration exercise on each start-up)
4) The LED will stay on as long as you have the write-protect status removed from the SYSRAM area, even if the HP-71B is off. (all FW versions)
5) The LED will blink when transmitting data over FRAM71’s UART (all FW versions)
6) FRAM71 Diagnostics

1. Basically, 2), 3) tell you that FRAM71 is properly inserted into the cardreader bay, and that all data lines can be interpreted. sounds banal, but I had 2 FRAM71 buyers who had never used the cardreader port, so the contact pins had accumulated some foreign matter which prevented FRAM71 from properly communicating with the HP-71B. at that time, FRAM71 firmware didn’t have this diagnostic feature, which led to a mild panic among all parties ;o) If you ever face this problem, use isopropyl (isopropanol) and a cotton swab to clean the contacts. _DO NOT_ use WD40 or denaturated alcohol.
2. With the shipped configuration, you can do a POKE and PEEK$ to address 0x30000. If PEEK$ result matches POKE, then you have verified functionality of the CMD-decoder, the bidirectional RAM-interface, the PC/DP counters, the ID-register multiplexer, the STR-phase-shifter, and the MMU.
3. The LED can be tested by installing / removing CN2:4 (read the fine manual)
   

hans

Useful information Hans, thanks for the detailed reply. Suggest you add this to the manual. Of course most FRAM71 users read the Forum, but many of us will recall this information was seen somewhere and I think most will consult the manual before a long search through this thread. There is MUCH useful info here, but I think the really important facts/specs and other reference type material should migrate into future manual updates. Just my opinion.

[Dave Frederickson]

(07-16-2015 11:47 AM)Hans Brueggemann Wrote:  6) FRAM71 Diagnostics

How do those work?

[Hans Brueggemann]

should read "diagnostics that you can perform...". edited above post to clarify.
FRAM71 has no dedicated internal circuitry to perform diagnostics by itself.

hans

[Egan Ford]

I'm finally getting some time to try to max out my FRAM71 config. I've read the manual multiple times as well as this thread. Please tell me if I've got this right.

I've removed all my ROMs but the 41 Translator (in port 1), I don't see any reason to remove it, plus I'm missing a port cover. I also have HP-IL B installed.

VER$:

Code:


HP71:2CDCC HPIL:1B FTH41:1A EDT:A

So my max available RAM is: 512 - 64 (SYSROM) - 32 (BASE RAM address space) - 48 (41 Translator) - 16 (HPIL) = 352 + 16 (base memory)

However I'm only able get 312 + 16

Code:


\POKE "2C000","939495969798999A9BAC000000000000"
>SHOW PORT
0.05  16384  2
1     16384  2
0      4096  0
0.01   4096  0
0.02   4096  0
0.03   4096  0
5     32768  0
5.01  32768  0
5.02  32768  0
5.03  32768  0
5.04  32768  0
5.05  32768  0
5.06  32768  0
5.07  32768  0
5.08  32768  0
5.09  16384  0
>MEM
 328085

Anything larger reports WRN: errors. What am I missing here? Thanks.

[Dave Frederickson]

(07-17-2015 01:59 AM)Egan Ford Wrote:  Anything larger reports WRN: errors. What am I missing here? Thanks.

(02-22-2015 06:30 PM)Hans Brueggemann Wrote:  4) as for the 16k vs. 32k memory requirements of the IL-ROM, i had totally forgotten about the note in the educalc article, so, yes, seems that the HPIL-ROM is sometimes configured into a 32 kByte address space, although the DIAG-ROM still reports only 32 kNibble. is there any further read on that anomaly?

I think it has something to do with ROM modules being installed. See EduCALC Technical Note #4 on the MoHPC flash drive.

Dave

[Egan Ford]

Ok, but I'm still about 16-32K short. Is there a tool to show the current 71B memory map? Thanks.

[Dave Frederickson]

Thank Paul Berger. MEMBUF and some of Paul's other programs.

[Hans Brueggemann]

For your convenience, i've added the FRAM71 Configuration sheet from the manual as *.doc file to the D/L section of post #1 in this thread. there's also a link to a must-read article about how HP-71B does configure its memory on start-up. that article also explains why the FRAM71 manual has to make a distinction between "F-addresses" and "H-addresses", and why "F-addresses don't necessarily match "H-addresses".

hans

[Hans Brueggemann]

As mentioned by Bob during his FRAM71 presenation in Nashville, FRAM71_V511 is finally out. You can find the firmware update file and the updated user's manual in post #1 of this thread. V511 will be the last update for quite a while, as i'm now concentrating on V600, which basically does away with 16KB-modules in favor of supporting programmable bank-switching between TOP and BOTTOM FRAM. unfortunately (as far as i can see by now) this will require a huge change in the configuration paradigm. Hence, i'm not quite sure as to whether users are willing to follow that change, so 511 is the way to go for all who are happy with their FRAM71s as it is today, while V600 and onward will be for all those who are a little bit more adventurous in stretching the limits of FRAM71!

Some comments on Bob's presentation may be in order:
- FRAM71 has and will continue to have experimental(!) UART support as described in the manual. however, the achievable data-rates (be it in plain BASIC or FORTH) top out at an underwhelming 30 (thirty) Bytes/sec. so, doing any useful things with that UART does require a driver, aka assembly-coded support. i'm still looking for a volunteer...
- Ancient versions of the firmware contained REDEYE IR-printing support that worked extremely well in conjunction with the HP82240A/B printers. however, REDEYE was abandoned sometime around the decision to support programmable bank-switching of F_Blocks, and therefore, it's highly unlikely that future firmware versions will revive REDEYE.
- 25 to go to make the next batch happen!

Hans
My sincere thanks go to Bob and Dave for their unbelievable enthusiasm and support!