SPI data transfer issue

[Bocdan]

*bump*

When can I expect the new software ? I am highly dependent on the sub-20 and the project is on hold while we wait for that update.

Dan

[xol]

HI,
Sorry for delay. I will make effort to finish it next week.

[xol]

Hi,
Implementation is done. You can see new API function documentation here:
http://www.xdimax.com/sub20/doc/HTML/su ... er_ess.htm

I'm waiting for release build to upload it.
You will need to update SUB-20 firmware.

You can quick test it with sub_app using -ss=E..... option. For example:

Code: Select all

./sub_app.exe --spi_cfg=e --ss="E1HHHHHv-0HHHHHv" --spi=10
./sub_app.exe --spi_cfg=e --ss="E0L^vL^vL^vL^vL^v" --spi=10
./sub_app.exe --spi_cfg=e --ss="E0HHv" --spi=10

You owe me oscilloscope screen shoots and corresponding code samples posted here as a example for other people who may want to use this function.

[xol]

Here it is:
viewtopic.php?f=2&t=3#p353

Waiting for your feedbacks

[Bocdan]

Alright, thanks for the modifications. I'll post samples once everything is working. As for oscilloscope screen shots it might take a while

Dan

[xol]

Thanks.
Most important for us is to know that feature is working and it really helps.

All the rest (samples and screenshots) is to help other people to understand new functionality we have invented together with you.

[Bocdan]

Well I did extensive tests with the new functionality sub_spi_transfer_ess, but it doesn't work. My next test will be to check the output on an oscilloscope.

BTW, on the page:
http://www.xdimax.com/sub20/doc/HTML/in ... er_ess.htm
The example is wrong, it should show sub_spi_transfer_ess not sub_spi_transfer

Ok, here are some results:
----------------------------------------
USING sub_spi_transfer
Output buffer contains {0xb0, 0x00, 0xb9, 0x00} (instruction bytes on first and third byte, "data" bytes on the second and fourth byte to shift the data read into the input buffer)
SS Config -> SS_CONF(E_SS0,SS_LO)
Input buffer gets {0x00, 0x80, 0x00, 0x04} (data bytes on the second and fourth bytes, means FIFO buffer ok, 4 new entries in the buffer)

Oddly it works even if I don't pulse between the first 2 bytes and the last 2 bytes (probably because the second command accesses a register after and that reading them don't depend on poping an entry on the FIFO buffer).

On the second pass (and every other pass after that) I obtain:
Input buffer gets {0x00, 0x83, 0x00, 0x20} (data bytes on the second and fourth bytes, means FIFO buffer overrun, 32 new entries in the buffer)
That's kinda normal because using sub_spi_transfer doesn't pulse between the data read to shift the data from the FIFO buffer and it's also why I made you do the sub_spi_transfer_ess.

----------------------------------------

USING sub_spi_transfer_ess
Output buffer contains {0xb0, 0x00, 0xb9, 0x00} (instruction bytes on first and third byte, "data" bytes on the second and fourth byte to shift the data read into the input buffer)
ESS Control = "0LL^-LL^-"
Input buffer gets {0x00, 0x80, 0x00, 0x00} (data bytes on the second and fourth bytes, means FIFO buffer ok, 0 new entries in the buffer)

Now getting 0 new entries is odd.

On the second pass (and every other pass after that) I obtain:
Input buffer gets {0x00, 0x83, 0x00, 0x00} (data bytes on the second and fourth bytes, means FIFO buffer overrun, 0 new entries in the buffer)

The overrun is normal because I don't read any data from the FIFO buffer. So, there is a problem with the new functionality.

----------------------------------------

So I tried mixing both methods so I can read data:

USING sub_spi_transfer
Output buffer contains {0xb0, 0x00, 0xb9, 0x00} (instruction bytes on first and third byte, "data" bytes on the second and fourth byte to shift the data read into the input buffer)
SS Config -> SS_CONF(E_SS0,SS_LO)
Input buffer gets {0x00, 0x80, 0x00, 0x03} (data bytes on the second and fourth bytes, means FIFO buffer ok, 3 new entries in the buffer)

USING sub_spi_transfer_ess
Output buffer contains {0xf2, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0xf2, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0xf2, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}
(instruction byte on first byte, "data" bytes on the rest to shift the data read into the input buffer)

ESS Control = "0LLLLLLL^-LLLLLLL^-LLLLLLL^-"
Input buffer gets something but the data is totally wrong (remember that everything used to work at 800Hz, now it won't even work at 100Hz)

On the second pass (and every other pass after that) I obtain:
USING sub_spi_transfer
Output buffer contains {0xb0, 0x00, 0xb9, 0x00} (instruction bytes on first and third byte, "data" bytes on the second and fourth byte to shift the data read into the input buffer)
SS Config -> SS_CONF(E_SS0,SS_LO)
Input buffer gets {0x00, 0x83, 0x00, 0x00} (data bytes on the second and fourth bytes, means FIFO buffer overrun, 0 new entries in the buffer)

Clearly the data doesn't get shifted in the FIFO buffer.

So my question is was it tested ? I mean did you use an oscilloscope to see it pulse ? If so, I'll connect an oscilloscope too and check if the correct signal is sent to the accelerometer.

Do you have an Idea on how to fix this ?

FYI, calls on both functions together lasts roughly 8.5ms so I'll be able to use the 1600Hz setting on the accelerometer but not the maximum setting of 3200Hz.

BTW, I updated the firmware to 2.9 and the drivers (with libs and header file).

Dan

[xol]

Hi,
There was a bug in DLL with _ess function. One of our customers reported the problem.
You can try to use attached DLL with a fix or wait for next release. The fixed DLL was tested again and should be OK.

[Bocdan]

Hi,

I tried the files you linked in your previous email. It works better but it still doesn't work as intended. The first multiple byte read with pulse inbetween works fine, but when I perform a second read (or any subsequent read) on the data the data, I get garbage and the FIFO buffer entry isn't poped.
Here are the 2 differents approaches:
--| FIRST |-- (works but takes 20ms to execute therefore I cannot use the maximum output rate of the accelerometer)
if (v_sAccelData.sFIFOStatus.uiEntries > 0)
{
v_sAccelInfo.sInfo.bRead = TRUE;
v_sAccelInfo.sInfo.bMultipleBytes = TRUE;
v_sAccelInfo.sInfo.eRegAdr = E_REG_DATA_X0;
v_acSPIBuffOut[0] = v_sAccelInfo.cRawData;
for (unsigned int v_uiInc = 1; v_uiInc < ACCEL_MB_READ_BUFF_SIZE; v_uiInc++)
{
v_acSPIBuffOut[v_uiInc] = NULL;
}

//|LLR> Do a multiple bytes read on DATA X0 register up to DATA Z1 register for data consistency for all entries.
for (unsigned int v_uiInc = 0; v_uiInc < v_sAccelData.sFIFOStatus.uiEntries; v_uiInc++)
{
v_iSPIResult = sub_spi_transfer(
v_pCDlg->m_shHandle,
v_acSPIBuffOut,
v_acSPIBuffIn,
ACCEL_MB_READ_BUFF_SIZE,
SS_CONF(E_SS0,SS_LO)
);

g_asAcqBuff[g_eActBuff][g_iBuffCurrIdx].sData.acX[0] = v_acSPIBuffIn[1];
g_asAcqBuff[g_eActBuff][g_iBuffCurrIdx].sData.acX[1] = v_acSPIBuffIn[2];
g_asAcqBuff[g_eActBuff][g_iBuffCurrIdx].sData.acY[0] = v_acSPIBuffIn[3];
g_asAcqBuff[g_eActBuff][g_iBuffCurrIdx].sData.acY[1] = v_acSPIBuffIn[4];
g_asAcqBuff[g_eActBuff][g_iBuffCurrIdx].sData.acZ[0] = v_acSPIBuffIn[5];
g_asAcqBuff[g_eActBuff][g_iBuffCurrIdx].sData.acZ[1] = v_acSPIBuffIn[6];
g_iBuffCurrIdx++;

//|LLR> Switch buffer when the active buffer is full.
if (g_iBuffCurrIdx == ACQ_BUFF_SIZE)
{
if (g_eActBuff == E_1ST_BUFF)
{
g_eActBuff = E_2ND_BUFF;
}
else
{
g_eActBuff = E_1ST_BUFF;
}
g_iBuffCurrIdx = 0;
}
}

--| SECOND |-- (doesnt work but takes 5ms to execute)
if (v_sAccelData.sFIFOStatus.uiEntries > 0)
{
v_sAccelInfo.sInfo.bRead = TRUE;
v_sAccelInfo.sInfo.bMultipleBytes = TRUE;
v_sAccelInfo.sInfo.eRegAdr = E_REG_DATA_X0;

v_iESSctrlIdx = 0;
v_acESSctrl[v_iESSctrlIdx] = '0';
v_iESSctrlIdx++;

//|LLR> Do a multiple bytes read on DATA X0 register up to DATA Z1 register for data consistency for all entries.
v_uiCount = 0;
while (v_uiCount < ACCEL_MB_READ_BUFF_SIZE * v_sAccelData.sFIFOStatus.uiEntries)
{
v_acSPIBuffOut[v_uiCount] = v_sAccelInfo.cRawData;
v_acESSctrl[v_iESSctrlIdx] = 'L';
v_iESSctrlIdx++;
for (unsigned int v_uiInc = 1; v_uiInc < ACCEL_MB_READ_BUFF_SIZE; v_uiInc++)
{
v_acSPIBuffOut[v_uiCount + v_uiInc] = NULL;
v_acESSctrl[v_iESSctrlIdx] = 'L';
v_iESSctrlIdx++;
}
v_acESSctrl[v_iESSctrlIdx] = '^';
v_iESSctrlIdx++;
v_acESSctrl[v_iESSctrlIdx] = '-';
v_iESSctrlIdx++;
v_uiCount += ACCEL_MB_READ_BUFF_SIZE;
}
v_acESSctrl[v_iESSctrlIdx] = NULL;

v_iSPIBuffSize = ACCEL_MB_READ_BUFF_SIZE * v_sAccelData.sFIFOStatus.uiEntries;

v_iSPIResult = sub_spi_transfer_ess(
v_pCDlg->m_shHandle,
v_acSPIBuffOut,
v_acSPIBuffIn,
v_iSPIBuffSize,
v_acESSctrl
);

//|LLR> Store all the newly acquired data into the acquisition buffer.
v_uiCount = 0;
while (v_uiCount < v_sAccelData.sFIFOStatus.uiEntries * ACCEL_MB_READ_BUFF_SIZE)
{
g_asAcqBuff[g_eActBuff][g_iBuffCurrIdx].sData.acX[0] = v_acSPIBuffIn[v_uiCount + 1];
g_asAcqBuff[g_eActBuff][g_iBuffCurrIdx].sData.acX[1] = v_acSPIBuffIn[v_uiCount + 2];
g_asAcqBuff[g_eActBuff][g_iBuffCurrIdx].sData.acY[0] = v_acSPIBuffIn[v_uiCount + 3];
g_asAcqBuff[g_eActBuff][g_iBuffCurrIdx].sData.acY[1] = v_acSPIBuffIn[v_uiCount + 4];
g_asAcqBuff[g_eActBuff][g_iBuffCurrIdx].sData.acZ[0] = v_acSPIBuffIn[v_uiCount + 5];
g_asAcqBuff[g_eActBuff][g_iBuffCurrIdx].sData.acZ[1] = v_acSPIBuffIn[v_uiCount + 6];
g_iBuffCurrIdx++;

//|LLR> Switch buffer when the active buffer is full.
if (g_iBuffCurrIdx == ACQ_BUFF_SIZE)
{
if (g_eActBuff == E_1ST_BUFF)
{
g_eActBuff = E_2ND_BUFF;
}
else
{
g_eActBuff = E_1ST_BUFF;
}
g_iBuffCurrIdx = 0;
}
v_uiCount += ACCEL_MB_READ_BUFF_SIZE;
}



Maybe you can help find the problem ? My guess is that it has something to do with the CS not being deasserted properly by sub_spi_transfer_ess which prevents the data from poping in the FIFO buffer of the accelerometer.


Dan

[xol]

HI,
I suggest you to take a scope and check how it looks.
In a 5 minutes you will get the answer where the problem is.