Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cypress: SPI FPGA test: tester always respond 0 when MODE other then 0 #11795

Closed
yarbcy opened this issue Nov 1, 2019 · 27 comments

Comments

@yarbcy
Copy link
Contributor

@yarbcy yarbcy commented Nov 1, 2019

Description of defect

Cypress: SPI FPGA test: tester always respond 0 when MODE other then 0.

Target(s) affected by this defect ?

Tested on CY8CKIT_062_WIFI_BT

Toolchain(s) (name and version) displaying this defect ?

Tested on GCC_ARM

What version of Mbed-os are you using (tag or sha) ?

Latest

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

N/A

How is this defect reproduced ?

Always.

@yarbcy

This comment has been minimized.

Copy link
Contributor Author

@yarbcy yarbcy commented Nov 1, 2019

@0xc0170 @mprse Please take a look.

@ciarmcom

This comment has been minimized.

Copy link
Member

@ciarmcom ciarmcom commented Nov 1, 2019

@mprse

This comment has been minimized.

Copy link
Member

@mprse mprse commented Nov 4, 2019

It's hard to guess what is wrong without the board. The following additional information would be helpful:

  • test output,
  • does the test pass if only single SPI - mode testing (MODE_1) test case is executed?
  • can you decrease number of transferred symbols in the test to 5 (TRANSFER_COUNT = 5) and provide a view from the logic analyzer for SPI - mode testing (MODE_1) test case?
@yarbcy

This comment has been minimized.

Copy link
Contributor Author

@yarbcy yarbcy commented Nov 4, 2019

@mprse
1) Test output:

080164352 - peripheral tested on port: peripheral=(1080164352) MOSI=(A0) MISO=(A1) SCLK=(A2) SSEL=(A3) ...:109::FAIL: Expected 1 Was 0
[1572858689.45][CONN][INF] found KV pair in stream: {{__testcase_finish;SPI - basic test;0;1}}, queued...
[1572858689.53][CONN][RXD] >>> 'SPI - basic test': 0 passed, 1 failed with reason 'Assertion Failed'
[1572858689.53][CONN][RXD]
[1572858689.60][CONN][RXD] >>> Test cases: 0 passed, 1 failed with reason 'Assertion Failed'
[1572858689.61][CONN][RXD] >>> TESTS FAILED!

  1. No it doesn't.
  2. It looks like no sense for me because when I set (TRANSFER_COUNT = 5) even MODE0 FAILED (PASSED when (TRANSFER_COUNT = 300)).
@mprse

This comment has been minimized.

Copy link
Member

@mprse mprse commented Nov 4, 2019

Looking at the provided log. It applies to SPI - basic test test case (this test case uses MODE == 0). It fails because unexpected data is received from SPI-slave (FPGA-Test-Shield).

In the test scenario we expect to have TRANSFER_COUNT 8-bit symbols transmitted in both directions:

MOSI: 0x00 0xFF 0xFE 0xFD ...
MISO: 0x00 0x01 0x02 0x03 ...

I suggest checking what is transmitted on the logic analyzer.
You can also try to comment out line 109 (allow the test to move forward) and verify the number of received symbols/checksum on the SPI-slave side (FPGA-Test-Shield) - lines 157, 158.

@yarbcy

This comment has been minimized.

Copy link
Contributor Author

@yarbcy yarbcy commented Nov 4, 2019

@mprse Please notice that log file is related to MODE == 1. It because I manualy change MODE == 0 -> MODE == 1 in line 175. Test case with MODE==0 passed witout any problems.

@yarbcy

This comment has been minimized.

Copy link
Contributor Author

@yarbcy yarbcy commented Nov 4, 2019

@mprse
Mode==0 log:

1080164352 - peripheral tested on port: peripheral=(1080164352) MOSI=(A0) MISO=(A1) SCLK=(A2) SSEL=(A3) ...succeeded
[1572863657.66][CONN][RXD] 1080492032 - Could not find pins to test peripheral
[1572863657.71][CONN][INF] found KV pair in stream: {{__testcase_finish;SPI - basic test;1;0}}, queued...
[1572863657.76][CONN][RXD] >>> 'SPI - basic test': 1 passed, 0 failed
[1572863657.76][CONN][RXD]
[1572863657.79][CONN][RXD] >>> Test cases: 1 passed, 0 failed

Mode==1 log:

1080164352 - peripheral tested on port: peripheral=(1080164352) MOSI=(A0) MISO=(A1) SCLK=(A2) SSEL=(A3) ...:109::FAIL: Expected 1 Was 0
[1572863733.97][CONN][INF] found KV pair in stream: {{__testcase_finish;SPI - mode testing (MODE_1);0;1}}, queued...
[1572863734.07][CONN][RXD] >>> 'SPI - mode testing (MODE_1)': 0 passed, 1 failed with reason 'Assertion Failed'
[1572863734.07][CONN][RXD]
[1572863734.13][CONN][RXD] >>> Test cases: 0 passed, 1 failed with reason 'Assertion Failed'
[1572863734.15][CONN][RXD] >>> TESTS FAILED!

@mprse

This comment has been minimized.

Copy link
Member

@mprse mprse commented Nov 4, 2019

OK.
I strongly suggest connecting the logic analyzer. This will prove that signals states are valid in MODE 1 (sclk idle low/sampling on the second edge).

@yarbcy

This comment has been minimized.

Copy link
Contributor Author

@yarbcy yarbcy commented Nov 4, 2019

@yarbcy

This comment has been minimized.

Copy link
Contributor Author

@yarbcy yarbcy commented Nov 4, 2019

@mprse

This comment has been minimized.

Copy link
Member

@mprse mprse commented Nov 4, 2019

I think you can drag the image file and drop it in the text box.

@yarbcy

This comment has been minimized.

Copy link
Contributor Author

@yarbcy yarbcy commented Nov 4, 2019

RemoteDesktopManager64_JYfBanX8Un

@mprse

This comment has been minimized.

Copy link
Member

@mprse mprse commented Nov 4, 2019

In MODE 1 sclk idle state is low and on the logic analyzer view, we can see that sclk idle state is high.

https://github.com/ARMmbed/fpga-ci-test-shield/blob/f69c6c393ecbd20fd80fadf2a7ed48b49457a905/rtl/spi_slave.v#L60

Please try to switch CYHAL_SPI_MODE_01_MSB to CYHAL_SPI_MODE_10_MSB:

switch (mode) {
default: // fallthrough
case 0:
hal_mode = CYHAL_SPI_MODE_00_MSB;
break;
case 1:
hal_mode = CYHAL_SPI_MODE_01_MSB;
break;
case 2:
hal_mode = CYHAL_SPI_MODE_10_MSB;
break;
case 3:
hal_mode = CYHAL_SPI_MODE_11_MSB;
break;
}

@mprse

This comment has been minimized.

Copy link
Member

@mprse mprse commented Nov 4, 2019

spi_format() calls cyhal_spi_init() with hal_mode == CYHAL_SPI_MODE_01_MSB == 2:

switch (mode) {
default: // fallthrough
case 0:
hal_mode = CYHAL_SPI_MODE_00_MSB;
break;
case 1:
hal_mode = CYHAL_SPI_MODE_01_MSB;
break;
case 2:
hal_mode = CYHAL_SPI_MODE_10_MSB;
break;
case 3:
hal_mode = CYHAL_SPI_MODE_11_MSB;
break;
}
if (CY_RSLT_SUCCESS != cyhal_spi_init(&(spi->hal_spi), mosi, miso, sclk, ssel, NULL, (uint8_t)bits, hal_mode, slave != 0)) {
MBED_ERROR(MBED_MAKE_ERROR(MBED_MODULE_DRIVER_SPI, MBED_ERROR_CODE_FAILED_OPERATION), "cyhal_spi_init");
}

cyhal_spi_init() calls cyhal_convert_mode_sclk() with mode == CYHAL_SPI_MODE_01_MSB == 2:

obj->clk_mode = cyhal_convert_mode_sclk(mode);
config_structure.sclkMode = obj->clk_mode;

I believe that cyhal_convert_mode_sclk() returns CY_SCB_SPI_CPHA0_CPOL1 in our case. That is why we have sclk idle state high:

static cy_en_scb_spi_sclk_mode_t cyhal_convert_mode_sclk(cyhal_spi_mode_t mode)
{
uint8_t sclk_mode = (mode & 0x6) >> 1;
switch (sclk_mode)
{
case 0:
return (CY_SCB_SPI_CPHA0_CPOL0);
case 1:
return (CY_SCB_SPI_CPHA0_CPOL1);
case 2:
return (CY_SCB_SPI_CPHA1_CPOL0);
case 3:
return (CY_SCB_SPI_CPHA1_CPOL1);
default:
return (CY_SCB_SPI_CPHA0_CPOL0);
}
}

@mprse

This comment has been minimized.

Copy link
Member

@mprse mprse commented Nov 4, 2019

I guess that the following comments are invalid:

/** Standard motorola SPI CPOL=0, CPHA=1 with MSB first operation */
CYHAL_SPI_MODE_01_MSB,

Should be:
/** Standard motorola SPI CPHA=0, CPOL=1 with MSB first operation */

To be consistent with:

CY_SCB_SPI_CPHA0_CPOL1 = 2U, /**< Clock is active high, data is changed on first edge */

@mprse

This comment has been minimized.

Copy link
Member

@mprse mprse commented Nov 4, 2019

@yarbcy Any updates?

@yarbcy

This comment has been minimized.

Copy link
Contributor Author

@yarbcy yarbcy commented Nov 4, 2019

RemoteDesktopManager64_Cc9OPw3JEe

@yarbcy

This comment has been minimized.

Copy link
Contributor Author

@yarbcy yarbcy commented Nov 4, 2019

@mprse I made debug session while calling SPI_Init().

@yarbcy

This comment has been minimized.

Copy link
Contributor Author

@yarbcy yarbcy commented Nov 4, 2019

@mprse Is it what you expected? (CY_SCB_SPI_CPHA0_CPOL1)

@mprse

This comment has been minimized.

Copy link
Member

@mprse mprse commented Nov 4, 2019

I see we expect CPHA_1_CPOL_0 for MODE 1.

@yarbcy

This comment has been minimized.

Copy link
Contributor Author

@yarbcy yarbcy commented Nov 4, 2019

Test case PASSED with MODE=1 and CY_SCB_SPI_CPHA1_CPOL0

@yarbcy

This comment has been minimized.

Copy link
Contributor Author

@yarbcy yarbcy commented Nov 4, 2019

Created internal merge request.

@mprse

This comment has been minimized.

Copy link
Member

@mprse mprse commented Nov 5, 2019

Are you going to create a fix for Cypress SPI driver in Mbed-os?

@yarbcy

This comment has been minimized.

Copy link
Contributor Author

@yarbcy yarbcy commented Nov 5, 2019

Yes.

@0xc0170

This comment has been minimized.

Copy link
Member

@0xc0170 0xc0170 commented Nov 5, 2019

Nice work !

@yarbcy

This comment has been minimized.

Copy link
Contributor Author

@yarbcy yarbcy commented Nov 5, 2019

@yarbcy

This comment has been minimized.

Copy link
Contributor Author

@yarbcy yarbcy commented Nov 14, 2019

Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.