⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 6521_readme.txt

📁 TDK 6521 SOC 芯片 DEMO程序
💻 TXT
📖 第 1 页 / 共 2 页
字号:
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$<enter>".
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
(64K 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_<model#>" 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 <project-name>.uv2
In the Keil project menu, select "rebuild all".
<project-name>.abs contains symbols, and can be loaded into the emulator.
<project-name>.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

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -