文件列表:

tdk6521 demo\6521_CLI.Uv2 (10919, 2006-10-02)
tdk6521 demo\6521_CLI_1e2w.hex (86853, 2006-03-13)
tdk6521 demo\6521_CLI_1e3w.hex (86264, 2006-03-13)
tdk6521 demo\6521_CLI_2e3wd.hex (87862, 2006-03-13)
tdk6521 demo\CE\ce21a03.ce (11533, 2006-09-13)
tdk6521 demo\CE\ce21a03.dat (2893, 2006-09-12)
tdk6521 demo\CE\ce21a03_ce.c (7219, 2006-09-13)
tdk6521 demo\CE\ce21a03_dat.c (3822, 2006-09-13)
tdk6521 demo\CE\ce21a04.ce (11533, 2006-09-13)
tdk6521 demo\CE\ce21a04.dat (2893, 2006-08-15)
tdk6521 demo\CE\ce21a04_ce.c (7219, 2006-09-13)
tdk6521 demo\CE\ce21a04_dat.c (3822, 2006-09-13)
tdk6521 demo\CE\ce_ce.h (1894, 2005-08-30)
tdk6521 demo\CE\ce_dat.h (1831, 2006-08-08)
tdk6521 demo\CE\ce_merge.c (7764, 2006-08-08)
tdk6521 demo\CE\ce_merge.doc (29696, 2006-07-11)
tdk6521 demo\CE\ce_merge.exe (131072, 2006-06-02)
tdk6521 demo\CE\io_merge.c (32801, 2006-08-08)
tdk6521 demo\CE\io_merge.exe (139264, 2006-07-12)
tdk6521 demo\CE\TEST.TXT (593, 2006-07-12)
tdk6521 demo\CE (0, 2006-03-13)
tdk6521 demo\CHECKSUM.BAT (78, 2006-08-08)
tdk6521 demo\CLEAN.BAT (355, 2006-08-08)
tdk6521 demo\cleansrc.bat (40, 2006-08-08)
tdk6521 demo\CLI\access.c (14725, 2006-10-12)
tdk6521 demo\CLI\access_x.c (4892, 2006-10-12)
tdk6521 demo\CLI\cli.c (19597, 2006-10-12)
tdk6521 demo\CLI\cli.h (6826, 2006-09-12)
tdk6521 demo\CLI\cmd_ce.c (11087, 2006-10-12)
tdk6521 demo\CLI\cmd_misc.c (18392, 2006-10-12)
tdk6521 demo\CLI\c_serial.c (10839, 2006-10-12)
tdk6521 demo\CLI\help.c (23743, 2006-10-12)
tdk6521 demo\CLI\help.h (2905, 2006-09-12)
tdk6521 demo\CLI\io.c (16479, 2006-10-12)
tdk6521 demo\CLI\io.h (5583, 2006-09-12)
tdk6521 demo\CLI\load.c (26591, 2006-10-12)
tdk6521 demo\CLI\profile.c (16755, 2006-10-12)
tdk6521 demo\CLI\ser0cli.c (17565, 2006-09-26)
tdk6521 demo\CLI\ser0cli.h (3315, 2006-09-12)
... ...

This file contains info on: 1. How to operate the firmware a bit, and some info on how to calibrate the chip, 2. How to read and compile the firmware, 3. a list of errata and anomalies in the chip and 4. errata and anomalies in the demo software. 5. Changes to the demo firmware, listed from the most recent revision, backward to earlier revisions. 1. Operating the code: When DIO_8 is jumpered to GND, the demo PCB communicates at 9600 BAUD 8 bits, no parity, 1 stop bit, XON/XOFF. When V3P3 is off, the code waits for it to return, and does not perform any battery mode demonstrations. This behavior is useful in meters that lack a battery, because the chip can operate at voltages below many other devices. When DIO_8 is jumpered to V3P3D (to indicate that a battery is attached to VBAT), the PCB communicates at 300 BAUD, 8 bits, no parity, 1 stop bit, XON/XOFF. When V3P3 is on, operation is normal. When V3P3 goes off, it demonstrates the battery modes. Press PB to see the most recent power measurement, even when the power remains off. After pressing reset with V3P3 off, the serial line interface prompts with "B>" indicating it is running in low-power "brownout mode". In this mode the sleep and power down commands work from the serial port, but power measurement is disabled. The 6521 has a smaller memory, so the on-line help had to be omitted. Most commands from earlier TSC demo code work correctly. M1 is the difference between the calibration temperature and ambient. This is usually inaccurate at start-up becuase the demo PCB is shipped uncalibrated. M2 is the mains frequency, from VA. M3.0 is the total imported milliwh of both IA and IB. M3.1 displays the imported milliWh of element A. M3.2 is the mWh of B. M4.x is the exported milliwh, M4.0 = totals, M4.1 = elements A, M4.2 = B. M5.x is the imported milliVARh. m6.x is the exported milliVARh. M11.x is the power factor. MR1.1 is Irms of A, MR1.2 is Irms of B. MR2.1 is Vrms of A, MR2.2 is Vrms of B. M9 is the clock, M10 the date. These are not correct until the clock is set: use RTThour.minute.sec, and RTDyear.mon.day.day-of-week. Unless a battery is present, the clock loses its data. The push button rotates through the LCD's displays. When reset is pressed, and the demo PCB is operating only from a battery (clip a 3V to 4V battery to VBAT on JP8, and disconnect V3P3 and the wall-transformer unit), the demo PCB starts in brownout mode. This is handy to experiment with the low power modes. It prompts "B>" Since brownout mode uses a 32 kHz MPU clock, up to 150 times slower than mission mode. The CE and metering are disabled to save power. The software does not automatically copy data to the CE's ram, or read the EEPROM, like a normal startup. Brownout mode can take up to 30 seconds to begin responding to serial commands. The demo code checks DIO_8 to tell it if a battery is present. Without a battery, a power failure can cause the MPU to operate below the safe operating voltage of an EEPROM or other component, and this can cause anomalies. So, since the demo kit is shipped without a battery, DIO_8 is jumpered to have no battery. Therefore, the demo code for sleep and LCD-only mode is disabled by default. To enable it jumper DIO_8 to V3P3D, and press reset. To calibrate the demo kit for temperature: Let your chip reach equilibrium temperature at room temperature (two seconds of power is reasonably close). On the firmware's RS-232 command line (from port 0), type "]7b$". This is the "temp_raw" junction temperature of the chip in hexadecimal, measured via a base junction. Store it in )14, "TEMP_NOM". To test this, view the temperature deviation from calibration (in C) with the command M1. The temperature difference from calibration will appear on the LCD. PPMC and PPMC2, at )B and )C should be set to -150 and -392 to compensate for the ADC's typical temperature variations. Other meter components are likely to be temperature-dependent, and their constants can be added to ppmc and ppmc2, the temperature adjustments for the ADC. See the SUG for an explanation. The firmware has temperature-compensation for the ADC. There's a simple serial interface in io\cal_ldr.c that resembles intel hex. It's to read and set calibration variables. See the SUG for more information. This code is small enough to fit in real meters to calibrate the meter. In many meter designs, phase offsets for current sensors are constant enough to be hard-coded; they are zero by default. The calibration currently stores the calibrations in EEPROM, but there are options to use the on-chip flash. 2. Reading and compiling the Demo code: To adapt the demo code to your operating requirements, see the software user's guide, (an authoritative source) or e-mail meter.support@teridian.com This version of demo code is for the 71M6521F, a single-phase electric power metering chip with 32K of code space that is able to measure watts, vars, I, V, frequency, and temperature to 0.1%. A preliminary experimental version of the demo code for the 71M6521D 16K 6521 demo code may be available in some versions of this package, along with an experimental version running a FLAG protocol. There is a version of demo code that runs in 8K, suitable for the 71M6521B. It uses pulse counting. There are versions of this code that run on a TSC 71M6511 (***K of flash), so that designs that grow beyond 32K of code can be supported. There are also experimental three-phase versions as well, ported to the TSC 71M6513. Contact meter.support@teridian.com for further information on these versions. To read the code, TSC recommends and uses "tag jumping" editors. See the file doc\edithelp.htm t.bat builds a tags file for most editors, using the free "exuberant ctags" utility available at sourceforge.net . This release has all the 8051 source code for the MPU. Projects: 6521_cli.uv2 can generate 3 different binaries: Targets: Phase A | Phase B | Phase C | CE code 1 element 2 wire VA IA | VA IB | N/A | ce21a04 1 element 3 wire VA (IA - IB)/ 2 | N/A | N/A | ce21a03 2 element 3 wire delta VA IA | VB IB | N/A | ce21a03 The files are in the following directories: - "Docs" contains edithelp.htm, and Excel spreadsheets that are examples of the calculations for calibration, real-time clock temperature adjustment, least significant bits, and the temperature compensation calculations that the firmware performs for "H" (high accuracy) parts. - "CE" contains proprietary microcode for the proprietary DSP front end, the "compute engine." - "CLI" contain code for the Demo code's command line interpreter. This is separated because few customers want it in their final meter. - DOCS contains documentation and spreadsheets to calculate constants. - "FLAG" contains a simplified, single-baud-rate but well-tested flag protocol. The subdirectory "GUI" (if present) contains an unsupported GUI that communicates via the flag protocol. - "IO" has the code to drive the chip's nonmetering peripherals. - "Main" contains the main loop, battery mode logic and default table for the demo. - "Main_" contains an options file with switches to enable or disable software features. Many combinations of options are untested, but even these may help provide a quick start for customer projects. - "Meter" contains the metering code. - "Util" contains utility code such as math, and libraries to copy data. How to compile the firmware: Run the Keil IDE. This build occurred with Keil uVision V3.03a, C compiler 8.02 Open (double click on) the project .uv2 In the Keil project menu, select "rebuild all". .abs contains symbols, and can be loaded into the emulator. .hex is a loadable executable. To get more code space, and customize the meter, the demo codes have compilation flags in options.h Setting a flag to zero disables a feature, saving space. To get a large amount of space, try setting CLI to 0. This disables the command line interpreter, the largest single feature, one not usually needed in a real meter. The meter can still be calibrated via the serial port using the "calibration loader." Keil's premium "professional developer's kit" can also provide more code space. For example, when compiled using the LX51 (premium) linker, the 32K 6521 demo code becomes less than 26K, and the 6521's flag example is less than 16K. clean.bat removes extraneous compiler-generated files. cleansrc.bat removes files moved into the 6510 directory by the DOS batch files. 3. Chip errata and surprising behavior on 71M6521A03: I numbers (e.g. I-6) are used by TSC to track issues with the firmware. Use of chip versions before A04 is not recommended. If reset more often than every 4/32768 of a second, the watchdog reset does not take effect. When MPU_DIV is set to a nonzero value, brownout mode runs at 32768/(2^MPU_DIV). This is often absurdly slow. The code that transitions to brownout should set MPU_DIV to 0 so that brownout mode runs at its maximum speed. After a reset, all the IO data is cleared. After sleep or LCD-only mode, all the RAM is random because it was turned off. To make data available in all states, store data in the EEPROM. This is an intentional feature, to save power. CE microcode is in flash, and cannot be written or read while the CE is running. This includes programming code from the emulator, and includes software breakpoints set by the emulator. The emulator has two hardware breakpoints, used by default as the first two breakpoints. These work well. These are intentional features. SFR E8 bit 7 has two uses: writing 0 clears the PLL_FALLING flag. Writing 1 resets the watchdog (the watchdog reset should be on SFR F8). The raw data from the ADC is left-aligned, shifted 9 bits to the left when compared comparable data from the 6511. Most data processed by CE is unchanged, but some data is raw, such as temp_raw, which changes DEG_SCALE, for example. After a power-on reset, the CPU starts running at 32KHz, with PLL_OK false. When the PLL settles, PLL_OK becomes true, and the CPU runs at the programmed speed. In brownout mode, the serial ports can only send at 300 baud. The clock is too slow to send a faster speed. The clocks run at 7/8 of 32kHz. This is an intentional feature; without the 7/8 clock, brownout would have no serial I/O in standard baud rates. The wake timer to wake from LCD-only or sleep mode has to be set at least 3/32768 of a second before setting sleep mode or LCD-only mode. The sag detection status is in the most significant byte of the CE's status register. It is revised before each CE_BUSY interrupt. The battery-mode measurement feature (Bit BME, and reading an auxiliary register) is not very repeatable from chip-to-chip. It has to be calibrated in some fashion. For example, the demo code has a failure limit (VBatMin at )17 ) for the battery which should be set during calibration in order to detect battery failures. The battery present jumper must also be set to enable battery failure detection (see section 4 below). If not properly programmed, the chip can lose data-notification interrupts. The xfer_busy interrupt is logically-ored with the RTC 1 second interrupt and fed into an edge-triggered interrupt, INT6. The interrupt flags for xfer_busy and RTC 1 second must be carefully cleared at reset and in the interrupt to assure that the edge for INT6 can recur. If either flag is set, it will prevent the next interrupt. If a flag is cleared without servicing its interrupt, the interrupt will be lost, and may hang. These flags can be set by hardware while the interrupt (and sometimes the start-up) code is running. The flags are in the same register as the watchdog. Instructions with read-modify write behavior should not be used to clear one of these flags, because that can (rarely) lose an interrupt. See xfer_rtc_isr() in Meter\IO652X.c The first byte read from a CE data registers has to be read below a certain slow MPU clock rate to give the CE memory time to respond. This issue also affects the ability of the emulator to read CE data ram. After one byte is read, the rest of the byte reads of that register can be at a normal pace. Likewise, the first write to a byte of a CE register must be slow. See memget_ce () and memset_ce() Meter\ce.c The EEPROM interface status register clocks at a slower rate than the MPU. Operation via interrupt is correct. When run by polling, after a command, the status can take 32 MPU clocks to become available. Verified working polling I2C driver code is available with this release (in IO\IICEEP.C). It has a brief, calibrated delay after each IIC command given to the hardware. There's also a prewritten bit-banging IIC interface that runs up to 260kHz with a 4.9mHz clock (in IO\IICDIO.C), but this appears to overload the available power in brownout mode. The real time clock can be written only one register every 13/32768 seconds (with a 32 kHz crystal), and the write will still fail if the write enable is not written to first. It can be read more quickly, but the read must make sure that two consecutive reads of the seconds register are identical before reading the other registers. The code is in "IO\rtc.c". The main watchdog cannot be disabled by any status in the chip, so that the chip will always restart if it is halted by a transient event. Also, the watchdog reset is very similar to a "Wake" from a sleep mode and not a hard reset. The auxiliary watchdog accessed from WDTREL is not recommended for use, and can only reset the CPU. Uart 0 does not work in mode zero. Timer 0 mode 2 does not work if timer 1 is in mode zero or one. When a 4.2mHz crystal is used, low power operation is much speedier, but duty cycles and frequencies for the serial port's optical modulation are inaccurate, and timings for the EEPROM and other interfaces vary by several percent. The chip stops and the emulator does not detect it when a MOVC operation fetches code from an address on which a hardware breakpoint is set. This might occur when debugging code that performs a checksum on itself. 4. Software issues in this version, 4.3.3: The 6521 has a mask-programmable version for high volume manufacturing. This eliminates any need to load code into the meter. ROM code should include the test code that TSC uses during manufacturing. This loads at an absolute address and takes about 0.5k. If you plan rommable code, e-mail meter.support@teridian.com An issue that came up in many situations was, "Does the user want to experiment with battery modes?" TSC ships the demo PCB without a battery. The code can be reconfigured for battery operation by jumpering DIO_8 to V3P3D, and attaching the positive terminal of a 3.6V battery to VBAT. In non-battery mode, the PLL_OK interrupt waits when it detects brownout mode. In battery mode, the interrupt calls a soft reset to transition to the state machine in main() (see main\main.c). DIO_8 also enables battery testing in meter\battest.c In a prototype meter, DIO_8 can be a test output, reset the PCB, detect tampering or act as a select line for multiple or microwire EEPROMs. See JP15, where it's brought out to a header. Some designers reset a meter periodically, often at midnight, so the meter software can be tested over a finite interval. To do this, attach DIO_8 to reset, and configure DIO_8 as an input except when performing the reset, so it does not fight the reset switch. In this demo PCB the pulse outputs have electrical headers, and can also be conveniently used as test outputs. The demo code util\oscope.h defines macros to instrument scope loops using the VAR pulse output. The demo code multiplexes the watt pulse and UART1's transmit onto the OPT_TX pin on J12 whenever transmission is not occurring. When setting temp_nom, it's easy to type ]18=1900000000 rather than ]18=+1900000000. With no plus sign the number is hex, and then ppmc and ppmc2 appear grossly wrong, and the meter tests badly out of spec. in temperature compensation. FLAG applications: The 7E1 UART mode is available! The UARTs cannot physically support 7N1 (use 7N2), 8E2 or 8O2 (try 8E1 or 8O1). All devices that require 1 or 1.5 stop bits will accept 2 stop bits. There is tested, sample FLAG code. The included FLAG code was thoroughly debugged, but is not in everyday use. Polling I2C and microwire drivers are available in the library source both for fast bit-banging (iic.h, iicdio.c, uwr.h, uwrdio.c) and using the chip's internal logic (iic.h, iiceep.c, uwr.h, uwreep.c). Both work with polling EEPROM code such as the sample code eepromp.c provided for the AT24C1024 serial EEPROM used on the demo PCBs. The demo microwire eeprom is a Microchip 93c76C, controlled by eepromp3.c. A known problem with the bit-banging eeprom code, iicdio.c, is that it causes A03 to enter sleep mode when used in brownout mode. This behavior has not been isolated, but may be caused by bus contention with the EEPROM, which could overload the current supply of the 6520 in brownout mode, and force it into sleep mode (This hardware behavior is a design feature to assure correct operation). The demo code as released uses the hardware eeprom driver, iiceep.c, which does not have this issue. I-36 Bad data from UARTs. If the CE is incompletely initialized, or the sag threshold is zero, the code to save the power registers may run frequently when there is no actual sag condition. This causes lost serial data because the sag code briefly speeds up the MPU's clock rate to maximum to save the power registers quickly. The same clock is used by the UART. The result are that a few percent of serial data are lost. The software pulse generators read the CE configuration and generate 50% duty-cycle pulses with the same units and scaling, but with more jitter. The outputs for PULSE3 and PULSE4 are on DIO1 and DIO2, respectively. This option disables OPT_TX and OPT_RX. If psoft.c is modified so OPT_RX is available, ser1cli.c is supposed to automatically switch between PULSE4 and serial output. Some REV 1 demo PCBs do not power the debug PCB's isolation chips in brownout mode. The result is that serial communications are lost when operating in brownout mode. I-37 The software pulse outputs (psoft.c) require too many CPU cycles to run at slow clock speeds. They run if main\options_gbl.h is changed to a 4.9mHz clock, and the code is recompiled. Meter equations other than equation 0 (single element) are available and integrated, but not as well-tested. Problems in 4.3.2, fixed in 4.3.3: I-40 As of chip version A04, MPU_DIV must be set to 0 when entering brownout-mode, so that brownout mode will run at the crystal's speed. I-41 Every loop that waits and resets the watchdog now includes a delay loop so that it doesn't reset the watchdog more often than once in 3/32768 of a second. The delay loop code is centralized now, in IO\delay.c, copes with different clock r ... ...

近期下载者：

相关文件：

评论：[我要评论] [举报此文件]

收藏者：