SPI interface data latches on the rising edge in mode 3

    Hai there,


    we migrating from PicoCOM2 to PicoCom4.
    Our application is working with the PicoCOM2 but makes SPI communication problems with the PicoCOM4 modul.


    Our SPI driver version is V3.2.
    .
    We operate in SPI mode 3, that means data is valid on the second rising edge.
    It also means that the data is latshed on each falling edge of the clock signal.
    See documentation

    Quote

    NSPI Driver, Native SPI Support, V3.1 (2011-11-14), page 6, Figure 10: SPI_Mode_3


    Unfortunatley the signal is not conform with specification because the data on the PicoCOM4 is not latched on the falling edge but instead on the rising edge. this chauses a malfunction of our SPI chip MCP4822 application.


    Please help us to solve the problem quickly.

    Mit freundlichen Grüßen
    Jörg Bartel


    Entwicklungsinenieur
    Saxon Junkalor GmbH
    Alte Landebahn 29
    06846 Dessau


    Tel: 0340 5510344

    I have currenlty tested this again, but SPI transfer looks good to me (see attachment).


    Could you please make sure that Mode3 is set correctly in registry? Please try to enable debug output and post the debug trace here:

    Code
    1. reg open \drivers\builtin\spi1
    2. reg set val debug dword 0xffff
    3. reg save
    4. reboot


    For verification here is my debug trace:

    Quote from "j.bartel@saxon.de"

    We operate in SPI mode 3, that means data is valid on the second rising edge.
    It also means that the data is latshed on each falling edge of the clock signal.


    No, in SPI Mode 3, data is valid on the first rising edge and it must also be latched on the rising edge of the clock signal. See attached image. Latching is done in the middle of the region of each bit, where the data is stable. Data changes on the falling edge. So latching on the falling edge would risk that the data is right within a change.

    Hai,


    after reconfiguration of the netdcucfg to port 2 und enabling the debug output in the boot loader, I get the following output:


    PS: I have emailed you the output pictures of out application.

    Mit freundlichen Grüßen
    Jörg Bartel


    Entwicklungsinenieur
    Saxon Junkalor GmbH
    Alte Landebahn 29
    06846 Dessau


    Tel: 0340 5510344

    Hai again,


    our messages some how got over each other. To your privous statement:

    Quote

    No, in SPI Mode 3, data is valid on the first rising edge and it must also be latched on the rising edge of the clock signal. See attached image. Latching is done in the middle of the region of each bit, where the data is stable. Data changes on the falling edge. So latching on the falling edge would risk that the data is right within a change.


    Just to clarify the meaning of "latching": data are changed at this moment, so in SPI mode 3 valid data are present between the latching process. That means data are valid on each rising edge of the CLK signal. Therefore the data change has to be done exactly in between the rising edges, so the data are changed/loaded at the falling edges (see your picture). For comparision look at the pictures I have emailed you. Also the device data sheet of the MCP4822 defines it clearly.


    PS: I can not find the "attach file"-button. How do you attach a picture for example in such a message?

    Mit freundlichen Grüßen
    Jörg Bartel


    Entwicklungsinenieur
    Saxon Junkalor GmbH
    Alte Landebahn 29
    06846 Dessau


    Tel: 0340 5510344

    Quote from "j.bartel@saxon.de"

    Just to clarify the meaning of "latching": data are changed at this moment, so in SPI mode 3 valid data are present between the latching process.


    No. Latching means that the receiving side takes the data at this moment into the internal latches (set of flip flops or a register). To get a stable result, the data must be stable while latching or the result is unpredictable. So the data must *not* be changing while latching.


    As the image shows, the data must be prepared between the falling edge and the rising edge of the clock. However it must be stable before the rising edge. Then at the rising edge, the data is fetched (latched) by the receiving device. After that the data lines can be modified again. However because it is not known how long the latching process (triggered by the rising edge) of a device is, the data should stay stable right up to the falling edge of the clock. So usually in SPI mode 3 the data changes shortly after the falling edge and is stable (valid) long before the rising edge. Latching is triggered by the rising edge, so data is copied to the target shortly after the rising edge.


    Quote

    PS: I can not find the "attach file"-button. How do you attach a picture for example in such a message?


    When you write a message, you can scroll down and will find a section "Dateianhang hochladen". Select a file in field "Dateiname" and then click on "Datei hinzufügen".

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.

    Does the debug trace above include executing of your programm?
    Doe you call IOCTL_NSPI_SET_METHOD within your application? Maybe
    Maybe you can write a small test-application that simply writes some bytes to make sure that the mode really is correct.


    Maybe you also can verify again that CAN really is deactivated. I don't see the CAN driver in your trace above, but this also could be the reason that the mode has been changed.

    Software developer, F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.

    Hai,


    1) I have checked the forum interface. I says:

    Quote

    Sie dürfen neue Themen in diesem Forum erstellen.
    Sie dürfen Antworten zu Themen in diesem Forum erstellen.
    Sie dürfen Ihre Beiträge in diesem Forum ändern.
    Sie dürfen Ihre Beiträge in diesem Forum löschen.
    Sie dürfen keine Dateianhänge in diesem Forum erstellen

    Can you give me access to append files to the forum?
    Another option would be to copy/paste pictures into the text reagion like an html email design.


    2) Your picture:

    Quote

    SPI-Mode3.png

    makes sense to me. In acordance to the specification it looks correct.
    I also agree with your definition of "latching" seen from the point of a receiving slave device. Basically I ment the same exept that I reffered to the master device action, which is the PicoCOM4 side.


    3) program executing:

    Quote

    Does the debug trace above include executing of your programm?

    No. I start the program after system has booted up using the debug interface of the VS2005 Software.


    4) call IOCTL_NSPI_SET_METHOD:

    Quote

    Doe you call IOCTL_NSPI_SET_METHOD within your application? Maybe

    No. I am not changing the SPI settings while our program is executed.


    5) test-application:

    Quote

    Maybe you can write a small test-application that simply writes some bytes to make sure that the mode really is correct.

    I have done the test using the ecaxt code you have provided. I still get the wrong output.
    This time I have tested two PicoCOM4 boards with different Hardware revisions. Test_001= R: 1.11 and Test_002= R:1.20.


    The board was configured with the following file:


    PS:Since I can not attach the pictures here I will email them to you instantly.

    Mit freundlichen Grüßen
    Jörg Bartel


    Entwicklungsinenieur
    Saxon Junkalor GmbH
    Alte Landebahn 29
    06846 Dessau


    Tel: 0340 5510344