another day of trying to sort out captures in simulink

Using this model:



just looked at the stack:

11097
11569

the difference is:
-472

which is somwhere arount the 500 that I expected.

the variable saved to memory from the output of the CAP block is always about 18000. I have no idea what this is.

This is what the help describes as happening:


Send data format

The type of data to output:

Send 2 elements (FIFO Buffer) -- Sends the latest two values. The output is updated when there are two elements in the FIFO, which is indicated by bit 13 or 11 or 9 being sent (CAP x FIFO).

Why 13 or 11 or 9?


If the CAP is polled when fewer than two elements are captures, old values are repeated. The CAP registers are read as follows: The CAP x FIFO status bits are read and the value is stored in the status flag.


The top value of the FIFO is read and stored in the output at index 0. The new top value of the FIFO (the previously stored bottom stack value) is read and stored in the output at index 1.


I had a thought that I may be loosing data due to the data format, however as it is set to "auto" it should not be loosing any data.

maybe not:

The auto option uses the datatype of a connected block that outputs data to this block. If this block does not receive any input, auto sets the dataype to double.

if I set the output data type to something larger than double...

tried uint32 and now it is changing but stillseems to bear no resemblance to the values in the stack.


Using the quick watch window (&I_pwm_testing_B.C28xCAP_o1[0]), I determined at which address the stack variables are stored in and added a "from memory" block to see their contents.



for some reason the contents of the saved memory locations are not the same as the contents of the stack - maybe I should not have uint32

now:

stack0(saved in memory) = 32512
stack1(saved in memory) = 21760

period(saved in memory) = 10752

which is correct subtraction, however:

I_pwm_testing_B.C28xCAP_o1[0] = 49331.0
I_pwm_testing_B.C28xCAP_o1[1] = 49801.0

which is nothing like what is saved in the memory.

Maybe it is something to do with the sample time and the memory only being saved once every sample time.

to test that theory, I have used memtest0 and memtest1 that are "from memory" at the same location. in theory, they should always have the same value in them...

and they do.

SAMPLE_TIME is now set to 0.0001sec. (10K)

on a rebuild the addresses for I_pwm_testing_B.C28xCAP_o1[0] and
I_pwm_testing_B.C28xCAP_o1[1] have changed. This is not a long term solution.


time to see how quick this baby can go.

Try sample time 0.00001 (100K)

Seems to work but has not helped my memory problems

Try sample time 0.000001 (1M)

Still seems to work but has still not helped the memory problems

I had better check if I can actually have too fast a sample time - otherwise I may not be increaing the sample time at all.

Try sample time 0.00000001 (100M)

Still has not crashed, however now all registers and memory locations except EvaRegs.CAP1FIFO are zero.

I had better go back to a realistic sample time and try to undersand what the outputs of the CAP block are doing. Maybe try 100K.

I now have C28xCAP_o2 changing between 1.0 and 3.0 which I need to understand. I noticed that some of the values I am looking at are double and some are uint16. As double seems to be the default for most of the cap values, i have changed all the memory locations to double for consistency.


THAT WAS MY PROBLEM. NOW THEY ALL AGREE.

The period now always seems to be -471.

I will try now to look at the period between any edge. This should either give me the high semiperiod or the low semiperiod.

I now have -210 or -261. If I change the current flow, I should get a much different ratio.

With the current setup to just before the /OC trips, the semiperiods are: -52 and -425.

this equates to: 10.9%

now to put my mind at ease, I will have a look at the semiperiod if I short out the V+ and the Vs pins of the IR2175. That should give me a 50% ontime.

226 and 245 = 48%

I guess that that is the fault of the poor shape of the square wave.