buffers that are able to provide more current

It seems that some of my problems with the current sensors are due to the innability of the 4050 or 4049s to provide adequate current to drive the leds in the optos.

Nic fourd that the 74 125 chip (as used in the ICD) could sink up to 25mA of current. As a result, I changed the 4049 that drove the optos from the IPWM signals to a 74125.

The waveform looks much nicer and now Labview has enough time to get the ADC signals as well (lack of crappy signal). This was only from a steady current source though. It may get crappy again when I am able to run the motor again.

more blown chips - how to protect them?

Effect - motor does not turn
Cause - dead gate drivers
Cause - dead voltage regulator
Cause - high voltage required for high current led to spike when the current requirement reduced.

I tried to stop this happening again by putting zeners to stop the voltage at 27v but as the fuse is 10A and each zener can only handle 176mA, I would need to have far too many zeners in parallel so that the fuse blew first.

Nic and I discussed using a DC DC converter for the power supply to the chips but we could not find any with a large enough input range for a reasonable price. We decided that it would be easier to just separate the grounds and use two separate power supplies.

finishing off ringing for the moment

I realised that I should have been meausing the high side between phase and gate drive signal rather than ground. this is for 33R




you can see here that there are none of the really high spikes but still a fair amount of ringing. I will just have a quick go at 120R to see if this gets a bit better.



that is no better - have a look at the low side

what size resistor to stop the ringing

as can be seen from the previous post, there is a lot of ringing with the 3r3 resistors

there is no ringing with the 1k resisistors - need somewhere in between

try 82R in series with 1k = about 75R

there is still a fair amount of ringing



one app note suggested that I should have the gate drive resistor as close as possible to the gate. I have moved an 82R as close to the gate for the following results



I tried adding a 16V zener between phase and the high gate drive but things went pear shaped.

instead, I tried to use a 330R for the gate drives




which looks pretty terrible

ty 33r close to gate

what is the minimum deadband that I can have with 3r3 resistors?

pulse width 50%
deadband prescaler from 31 to 1
deadband period left at 15

this setup does not draw too much current (indicating that the deadband is adequate)



put on the 3r3s on A' B' and C' and check the shapes for six wire simple

does not draw too much current which is a good start

still on HE = 1

here is the image for A and B



and for C




motor does not turn - increase the voltage factor from 350 to 700

also probably did not turn as I did not have the hall effects plugged in

turns now but is drawing heaps of current - better get a bit more deadband

changed both deadband prescalers to 4

still drawing too much current - here is the crossover point



try a prescaler of 8 and then it is time to attempt to get rid of the ringing

here is the ringing in the deadband zone with the

photos do not seem to be working at the moment see folder 060606

for deadband prescaler = 8

checking six wire open loop program with 3R3 gate resistors

HE = 1
A = 0
B = -1
C = 1

as expected, A and B have the low gate on all the time (barring the dead band) - see below



A little more interesting is phase C which is meant to be high but is only on for maybe 20% of the time (due to the huge amount of deadband)



I have left the 1k resistors on A' B' and C' and the interesting comparison is of B' which should be high. As you can see from the image below, it is proably high for a lot longer than the previous image.




the obvious thing at this stage would be to see how much deadband I can get away with on A, B and C with the 3r3 resistors

Gate drive resistors

from measurements, it has become clear that the gate drive resistors are too large.

here is the gate drive signal before the resistor




here is the gate drive signal after the 1K gate drive resistor



I decided that after seeing several reference designs (see binder with "gate drive app notes" that I should try a 3r3 resistor

here is the gate drive signal after the 3.3R resistor



I will go with that for each of the resistors. The only problem for having a lower resitsor value is apparently if there is too much ringing. I cannot see that.

these shapes are great, unfortunately the motor does not turn when these gate drive resistors are used. The motor seems to prefer it when the gate drive signal is a crappy shape.

XTIMING0

201343 actually works - try to remove active bit

110001000001111111

200831

works - try on 6

definitely does not work

110001001001111111

201343

i have had real trouble getting these timing registers to update.

I have tried to restart everythign but that does not help. I am just getting the default values of these registers

more external memory timing

I determined yesterday that the timing selections did not work if I assumed that Xready was not used.

That was at the minimum timing settings for xready but I will assume for the moment that it must use xready as that works.

I still cannot get access to the datasheets for the external memory chips to see if they use xready.

I now have access to the data sheet for the IS61LV6416-105 and I think that there is no connection to xready. This would be an output from the external memory chip and the only control signals are inputs.

The fastest access time that can be expected is 8ns.

The easiest way to configure this would be to assume that xready is not used and increase the timings until it works. Go to a maximum timing but with xready disabled to see if there is any chance that this will work.

below is the default changed to have xready = 0.

0000 0000 0100 0011 0011 1111 1111 1111

or

00000000010000110011111111111111

or

4407295

(31-24) 0000 0000 - reserved
(23) 0 - reserved
(22) 1 - X2TIMING
(21-18) 00 00 - reserved
(17-16) 11 - XSIZE
(15) 0 - READYMODE
(14) 0 - USEREADY
(13-12) 11 - XRDLEAD
(11-9) 111 - XRDACTIVE
(8) 1 - XRDTRIAL
(7) 1- XRDTRIAL
(6-5) 11 - XWRLEAD
(4-2) 111 - XWRACTIVE
(1-0) 11- XWRTRIAL

XintfRegs.XTIMING6.all = 4407295;

runs okay

try to remove all the write parts to simplify (last 7 bits)

00000000010000110011111110000000

or

4407168

works (as expected)

try changing down to xtiming2 = 0

00000000000000110011111110000000

212864

works

lets summarise

(31-24) 0000 0000 - reserved
(23) 0 - reserved
(22) 0 - X2TIMING
(21-18) 00 00 - reserved
(17-16) 11 - XSIZE
(15) 0 - READYMODE
(14) 0 - USEREADY
(13-12) 11 - XRDLEAD
(11-9) 111 - XRDACTIVE
(8-7) 11 - XRDTRIAL
(6-5) 00 - XWRLEAD
(4-2) 000 - XWRACTIVE
(1-0) 00- XWRTRIAL


try reducing XRDLEAD XRDACTIVE and XRDTRIAL to 1 each

00000000000000110001001010000000

or

201344

works

I know that lead must be 1 - lets see if either active or trail can be 0

try trail

00000000000000110001001000000000

works

try active

00000000000000110001000000000000

200704

does not work!!

00000000000000110001001000000000
201216

must be the answer

but...

Trouble Writing Target CPU memory: Error 0x00000002/-1153 Error during: Memory, The memory at 0x00100002 continually indicated it was 'not ready' All memory operations currently in progress were aborted in order to regain control of the processor. This is considered a catastrophic event, but the debugger should still be able to access memory and CPU registers. System state has been altered. It is strongly advised that the processor should be reset before resuming execution,


maybe I should set up the write states again

00000000000000110001001001111111

201343

works fine

now try to do the same to zone 0 (encoder)

201343


does not work

start another post on this topic later - home time

extermal memory timing

try chris' external memory timing

XintfRegs.XTIMING6.all = 202281;

motor does not turn

change back

from the data sheet, here is an example of valid timings when not sampling XREADY

0000 0000 0100 0011 1001 0000 0010 0000
or
00000000010000111001000000100000
or
4427808

(31-24) 0000 0000 - reserved
(23) 0 - reserved
(22) 1 - X2TIMING
(21-18) 00 00 - reserved
(17-16) 11 - XSIZE
(15) 1 - READYMODE
(14) 0 - USEREADY
(13-12) 01 - XRDLEAD
(11-9) 000 - XRDACTIVE
(8) 0 - XRDTRIAL
(7) 0- XRDTRIAL
(6-5) 01 - XWRLEAD
(4-2) 000 - XWRACTIVE
(1-0) 00- XWRTRIAL

motor makes a lot of ugly noise but does not run

I must need to use XREADY

I cannot find the data sheet for the external memory that I need to determine the wait states as the internet is playing up.

I will work on the current sensor problems instead.

block wave lookup for encoder

I have done this two ways, one with equal spacing for all the states and one directly from the logged data (ie which hall state corresponds to each encoder reading)

After a lot of stuff ups, i have two plots that closely resemble each other and sort of work. I think that they are not working completly properly because of the access times to external memory.

I think that I will use the equal spacing one as then I know what the block wave is.

Here are the relationships from the two:

Equal spacing



Experimental



I ref

manually adding lookups and using pragma

added to custom global variables:

#pragma DATA_SECTION(v, "lookup");
float v = 10;

works

try

#pragma DATA_SECTION(IaLookup, "lookup");
int16 IaLookup[] = { 0, 0, 1, 1, -1, -1, 0 };

motor turns but does not write to memory (or maybe it does) see watch window

add ib and ic



#pragma DATA_SECTION(IaLookup, "lookup");
int16 IaLookup[] = { 0, 0, 1, 1, -1, -1, 0 };

#pragma DATA_SECTION(IbLookup, "lookup");
int16 IbLookup[] = { 0, -1, 0, -1, 1, 0, 1 };

#pragma DATA_SECTION(IcLookup, "lookup");
int16 IcLookup[] = { 0, 1, -1, 0, 0, 1, -1 };

now try to change the code which references this stuff

works - thank bloody hell!!

try to make the generation a bit easier.

does not work trying to set IaLookup = afm_060601_P.Ia_lookup_table

xintf memory timing registers

there are two possible options available to me at this stage, I can either check the speed of access to the external memory map or I can try to get the program to work by modifying the "full memory map" cmd file.


there is info in the previously referenced post on dsp related about timing

What Simone has written is excellent advice, but you also need to set
up the external interface timing or your program will run much, much
more slowly. The default setting for the timing at hardware reset is
52 clock cycles for each read or write of the external RAM.

The boards we developed for our product with the 2812 have 128K words
of SRAM mapped to the XCS6AND7 chip select, twice as much as the
eZdsp. The SRAM is 15 ns access time. We also need to use the
external clock out at half the processor core speed, because that
clock is used by a CPLD and other logic that is 100 MHz max.

Here are our settings for the external interface generally, and this
particular chip select:

XintfRegs.XINTCNF2.all = 0x00004C17;
XintfRegs.XTIMING6.all = 0x00031629;

This gives us an external clock out of 70 MHz (our DSP runs at 5 times
a 28 MHz crystal), and SRAM read and write cycles of 4 clocks each.

The 2812 has an extremely long setup time for data read from external
memory, about 13 or 14 ns, so you need almost 0 ns RAM to be able to
read in 3 clocks. The write time could be 3 clocks, but since
external bus cycles always start on a rising edge of the external
clock, there is no overall savings for setting the write time to 3
clocks, another RAM access can't start during that fourth cycle
anyway.

I don't have the definitions of the fields in those registers handy,
but if you map the hex values into bits in the registers as defined in
the XINTF data sheet you should be able to figure them out.


here the bloke suggests that;

XintfRegs.XTIMING6.all = 0x00031629;

I have:

XintfRegs.XTIMING6.all = 0x04456447;

from the external interface documentation (SPRU067C) p27 the settings that they suggest are:

0x00031629

in binary

0000 0000 0000 0011 0001 0110 0010 1001

split up:

(31-24) 0000 0000 - reserved
(23) 0 - reserved
(22) 0 - X2TIMING
(21-18) 00 00 - reserved
(17-16) 11 - XSIZE
(15) 0 - READYMODE
(14) 0 - USEREADY
(13-12) 01 - XRDLEAD
(11-9) 011 - XRDACTIVE
(8) 0 - XRDTRIAL
(7) 0- XRDTRIAL
(6-5) 01 - XWRLEAD
(4-2) 010 - XWRACTIVE
(1-0) 01- XWRTRIAL

current

0000 0000 0100 0011 1111 1111 1111 1111

split up:

(31-24) 0000 0000 - reserved
(23) 0 - reserved
(22) 1 - X2TIMING
(21-18) 00 00 - reserved
(17-16) 11 - XSIZE
(15) 1 - READYMODE
(14) 1 - USEREADY
(13-12) 11 - XRDLEAD
(11-9) 111 - XRDACTIVE
(8) 1 - XRDTRIAL
(7) 1- XRDTRIAL
(6-5) 11 - XWRLEAD
(4-2) 111 - XWRACTIVE
(1-0) 11- XWRTRIAL

before I spend any more time on this one, I think I should just try to see if it works with their settings

I have put

/* external memeory timing setup */
XintfRegs.XTIMING6.all = 0x00031629;

into my iniitalisation routine

check first without the memory map adjusted

compiles, loads, does not run

commented out that line just to check it was the culprit

motor runs again

lets look at a direct comparison

X2TIMING - current: 1, chris: 0
scaling factor - 1 is default and doubles XWRLEAD, XWRACTIVE and XWRTRIAL. 0 keeps them the same

XSIZE - current: 11, chris: 11
these must be always written as 11, any other combination will result in incorrect XINTF behaviour.... interesting

READYMODE - current: 1, chris: 0
0 - synchronous, 1 - asynchrounous

USERREADY - current: 1, chris: 0
is XREADY used? 1 - yes, 0 no

XRDLEAD - current: 11, chris: 01
this defines the read cycle lead period
note that this is mulitplied by X2TIMING

00 - invalid
01 - 1 XTIMCLK cycle
10 - 2 XTIMCLK cycles
11 - 3 XTIMCLK cycles

XRDACTIVE - current: 111, chris: 011
this defines the read cycle active wait period
note that this is mulitplied by X2TIMING

000 - 0
001 - 1 XTIMCLK cycle
010 - 2 XTIMCLK cycles
011 - 3 XTIMCLK cycles
100 - 4 XTIMCLK cycles
101 - 5 XTIMCLK cycles
110 - 6 XTIMCLK cycles
111 - 7 XTIMCLK cycles

XRDTRIAL - current: 11, chris: 00
this defines the read cycle trail period
note that this is mulitplied by X2TIMING

00 - 0
01 - 1 XTIMCLK cycle
10 - 2 XTIMCLK cycles
11 - 3 XTIMCLK cycles

XWRLEAD - current: 11, chris: 01
this defines the write cycle lead period
note that this is mulitplied by X2TIMING

00 - invalid
01 - 1 XTIMCLK cycle
10 - 2 XTIMCLK cycles
11 - 3 XTIMCLK cycles

XWRACTIVE - current: 111, chris: 010
this defines the write cycle active wait period
note that this is mulitplied by X2TIMING

000 - 0
001 - 1 XTIMCLK cycle
010 - 2 XTIMCLK cycles
011 - 3 XTIMCLK cycles
100 - 4 XTIMCLK cycles
101 - 5 XTIMCLK cycles
110 - 6 XTIMCLK cycles
111 - 7 XTIMCLK cycles

XWRTRIAL - current: 111, chris:01
this defines the write cycle trail period
note that this is mulitplied by X2TIMING

00 - 0
01 - 1 XTIMCLK cycle
10 - 2 XTIMCLK cycles
11 - 3 XTIMCLK cycles

the most obvious change that I need to make is to avoid the use of xready

ie changing from

0000 0000 0100 0011 1111 1111 1111 1111

to
0000 0000 0100 0011 1011 1111 1111 1111
or
10000111011111111111111
or
4440063 in decimal
or
43BFFF in hex

compiles, loads, motor does not work and Xtiming6 does not change

when I try to define the same value (4456447) the motor works

try defining 4440063 in decimal rather than hex

motor works and userready is now 0 (not using xready)

change .ebss to zone6

builds, loads, motor does not work

try to avoid the avoid asynchronous (late)

10000110011111111111111
or
4407295


change back .ebss to DRAM for this trial

works - change to ZONE6

does not work

try chris' number but in dec

does not work - bedtime

tomorrow I should try to use the full_memory_map and modify it.

change back to 4407295 and dramho

works

on further checking, synchronous does not work. use 4440063

checking again - it does work - definetly bed time

memory mapping

I need to understand why I cannot use the external memory location of ZONE6 to store my lookup tables.

The lookup tables are stored in .ebss which is fine as long as the memory map stores that in DRAMH0. As soon as I attempt to store that in ZONE6, the data is stored there, the program compiles, however the motor will not run.

Nic passed on to me a link:

http://www.dsprelated.com/showmessage/29197/1.php

which had some stuff that I am already doing but had some wierd stuff about pragma directives.


you have to insert a pragma directive:
#pragma DATA_SECTION(v, "FFTv");
float v[10];

this is difficult to implement in my program as i do not really have a variable "v" that I can refer to. I have tried using both afm_060601_P.Ia_lookup and just afm_060601_P, but both times I get errors.

just to check if it would work, I tried:

//#pragma DATA_SECTION(v, "lookup");
//float v;
//float v = 10;

with this in the cmd file

.lookup : > ZONE6, PAGE = 1

If that worked then it was possible that i could include the lookups manually.

the program compiled, but the motor did not run.

Taking out that pragma directive allowed it to work again.

testing the use of memory locations in external memory

I put a "to memory" block and a "from memory" block that referenced external memory which works.

I will try to put that inline so that for the motor to run the memory access must work.

runs fine

looking at the code, I can see no reason why this access of external data works and the other does not.

try again

still does not work. I am sure that there shoul d be an /XZC6AND7 chip select command before the read to memory. Nic has just told me that ther

I cannot see that in the c code, but it may be in the assember

3F82F5

where does the data in the data file live

there are several sections that are stored in DRAMH0 in the internal memory map and in ZONE6 for the full memory map. I need to figure out which of these sections the parameters are stored in.

Internal memory map:

.bss : > DRAMH0, PAGE = 1
.ebss : > DRAMH0, PAGE = 1
.const : > DRAMH0, PAGE = 1
.econst : > DRAMH0, PAGE = 1
.sysmem : > DRAMH0, PAGE = 1

Full memory map:

.ebss : > ZONE6 PAGE = 1
.econst : > ZONE6 PAGE = 1
.esysmem : > ZONE6 PAGE = 1


Using the internal memory map the afm_060531_P is stored at 0x00008080 (which is in LO SARAM) and the motor runs.

I have tried to move the DRAMHO to 0x0100000 (zone 6)

file compiles with no errors (as expected)

file load (as expected)

motor does not run (as expected)

it is clear that as soon as stuff is moved to external memory the motor does not run.

I will try to intoduce a ZONE6 but move DRAMH0 back to internal

ZONE6 : origin = 0x100000, length = 0x002000

file compiles with no errors (as expected)

file load (as expected)

motor runs (as expected)

now I will try to move some of the stuff that is in DRAMH0 to ZONE6

try .const first

motor works but does not seem to have moved anything to ZONE6

try .ebss

the motor did not work and afm_060531_P has moved

try .econst only

that puts the PieVectTableInit there as well as FL1 FSL1.

motor works for that one which indicates that external memory can be accessed.

.ebss is the answer and should be stored in ZONE6 but I need to find out why it does not work

I have now stored all these findings in afm.cmd

works when nothing is referencing ZONE6