Anybus CompactCom M40 ModbusTCP - SPI communication between host and module get stuck at ABP_ANB_STATE_SETUP

Anybus Support Embedded
#1

Hello,

I have a problem with my Anybus CompactCom M40 ModbusTCP. The SPI communication between host and module get stuck at ABP_ANB_STATE_SETUP. Becaus of that I need some help to fix this problem.

  1. Environmental conditions:
    I have connected a Anybus CompactCom M40 ModbusTCP module with the starterkit to a microcontroller of microchip (ATmega2560). The preferred communication between the host and the module should be SPI. I have adapted the generic-examplecode from the HMS-website in compliance with the HMSI-27-334.pdf (Host Application Implementation Guide) but I am stuck at the end of Step 1 in the Guide. My module seems to get stuck at ABP_ANB_STATE_SETUP (right LED on the module shines green. Left LED on the module is off). But I have made some debugging and measurements to make it maybe more possible and easier for you to help me.

  2. Send data from the host:
    I have printed out every byte of data before I store it into the send-register of the controller. What I can see and what I have verified is that the host tries to send the same data every call of the driver. I have read the hms-hmsi-216-125.pdf (Software Design guide chapter SPI) and analyzed the send data. Every byte seems to be what it has to be.

The send data is the following (in hex):
0x85 0x00 0x08 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x6A 0x77 0x3E 0x1C 0x00 0x00

  1. receive data from the module:
    I have also printed out the received data from the module, but this data is different at the most time
    The received data from the CompactCom-Module for example is the following:
    0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x33 0x01 0x06 0xB8 0x11 0x8E 0x0E 0x71 0xB6 0x71 0xB6 0x71 0xB6 0x71 0xB6 0x71 0xA9 0xC0 0x00 0x00 0x00 0x18

Further more I have read in the Software Design Guide that it is normal that the host tries to send every call the same data until he get a good CRC.

  1. CRC-Function
    After I have read some posts in this forum I tried to analyze the CRC32-Function of the driver and I have tested this function with the examples in Appendix H. For my surprise the calculated crc does NOT match with the crc of the example. So I changed the code of the function to the example code given in appendix H. After that, the function calculated the correct crc for every example. But for my surprise, this did not changed anything. The behavior of the driver using SPI as described at the beginning of this post is still the same.

  2. physical send and receive data
    After that I have analyzed the send and received data with a logic analyzer. The data on the MOSI and MISO-wires are still the same as described. I have also verified with a oscilloscop, that the voltage-levels of the data is good enough. Nevertheless I have stepped down the speed of the spi transaction in little steps from 8MHz down to 0,5MHz Clock-Speed. But this did not changed anything either.

  3. configuration of the driver
    After I still spend to much time to make it run, I tried to change the communication channel from SPI to serial. This worked at the first try. The module starts as expected and can communicate over the ethernet-network. So I thought that the driver should be configured correctly, because I only changed the communication channel. I have noticed that the driver uses a crc16-function for serial communication. This function works as expected and described in appendix G of the software design guide. I have tested it with the examples given in there. But as I said, I have tried out the two algorithms for the Crc32 function and this did not changed anything.

Further more I have recognized that the serial communication is described as not recommended for the M40 modules in the documentation. I wonder why it is not recommended.

  1. SPI-Configuration
    After I have read some more posts in this forum, I have tried out the 4 possible SPI configurations for the host controller (CPOL and CPHA (Clock polarity and Clock phase)). But this did not changed anything either.

  2. printouts from the debug functionality of the driver.
    For the sake of completeness I have also used the printouts from the driver itself. I think that this does not seem to be very helpful but I do not want to hide them. I have enabled ABCC_CFG_ERR_REPORTING_ENABLED, ABCC_CFG_DEBUG_MESSAGING and ABCC_CFG_DEBUG_CMD_SEQ_ENABLED:
    Mem: Buffer allocated: 0x00000fe2
    CmdSeq(6c6)->00
    Command queued: MsgBuf:0x00000fe2 SrcId:0x00
    CmdQ status: 1(2)
    Outstanding commands: 1
    ANB_STATUS: ABP_ANB_STATE_SETUP
    ABCC watchdog timeout

I have added every information I have until yet to maybe short the process of support on this topic. But the result of that was that this post is very long. I apologize for my maybe spooky englisch, because it is not my mother language.

I hope someone of you can help me to solve this problem. I am also interested why the vanilla crc32 function of the generic driver does not calculate the same crcs as described in the documentation. Further more I am interested why the serial communication is not recommended for the M40 modules.

Best Regards
zorakon

#2

Hello,

I would start of with saying I would recommend reaching out to your local support team via mysupport.hms.se this might make it easier and quicker for you to get support for an issue like this.

If you are seeing the startup stop right at ABP_ANB_STATE_SETUP it sounds like you are not getting any communication over SPI .

Have you verified that the operating modes are set correctly? Do you see the Slave select change states? What about the clock?

How are you verifying the expected data you are sending matches what is on the line? Do you have any a Saleae logic analyzer you could use to verify the data on the MOSI and MISO pins?

SPI is generally faster then serial and synchronous.

Regarding the CRC, I am not sure why the driver code differs from the example. Do you know what version of the application code you are using?

Deryck

#4

I will check if I could get in contact with the mentioned local support.

Yes I verified that. The pins OM3 - 1 are connected to GND and the OM0 signal is connected to 3,3V.

Yes I checked this with a logic analyzer and an oscilloscope.

Yes I am using a Saleae logic analyzer. I printed every byte I want to send over the SPI directly from the controller on an terminal. At the same time I use a saleae logic analyzer connected to every 4 SPI-wires to check which data is on the MOSI and MISO pin.

Is this the only reason why serial is documented as “not recommended” for the M40?

I looked it up in the “abcc_versions.h”. The Version of the starterkit is V3.06.01. The version of the ABCC Driver is V5.06.01. The version of the ABP files in the starter kit is V7.72.01.

Best regards
zorakon

#5

Over all it sounds like you should have the compactcom configured correctly. Are you using this Saleae plugin to analyze the SPI traffic? perhaps this will highlight what is going wrong. https://github.com/hms-networks/AbccSpiAnalyzer

#6

This plugin seems to be very helpful. I will compile and install it tomorrow morning. After that I will run the analyzer again and try to attach the results in this forum. Maybe this could help.

#7

Getting this plugin working should be a big help. There are precompiled versions available.
https://github.com/hms-networks/AbccSpiAnalyzer/releases

Deryck

#8

Hello,

I now installed the plugin and made some records of the SPI transactions:

SPIFrame1
SPIFrame11646×225 34.8 KB

SPIFrame2
SPIFrame21674×221 30.1 KB

SPIFrame3
SPIFrame31676×232 34 KB

SPIFrame4
SPIFrame4262×520 9.01 KB

As I said the data on the MOSI-line definitely looks like it should. As I described in the first message the host-application-driver sends the initial message again and again, because the received CRC is invalid. This is exactly what the plugin calculated too. The behavior of the driver seems to be what it should be. But the send crc of the M40-Module seems to be wrong.

The only explanation I have is, that the module did not received the same data as we can see it on the logic analyzer results. In the documentation I found out that the module will answer with a destroyed crc to initiate a retransmit if he get an invalid crc on the MOSI-line. This could be the reason why the answered crc is invalid. But I have no explanation why the module did not receive the right crc.

I hope this can help to find out what is going on.

Best regards
zorakon

#9

I have checked the crc32-funtion again after I had an idea. At the time I have tried to verify the crc32-function of the driver with the examples given in the software-guide appendix H I made a mistake because of a missing information in the appendix H. I had to interpret the bytes given in the example as a 16-bit-value. So the example values 0x01 and 0x02 have to be combined to 0x0201. After that I get the same results of this function as it should be.

This does not solve my big problem with the SPI connection, but it gives an answer to this unsolved question. So nothing changed until yet. The crc32 function of the generic driver still works as it should be. This is what the results of the plugin of the logic analyzer said too.

Best regards
zorakon

#10

It is starting to look like this could be an issue with the CRC. Could you share the actual capture? This might help me understand the issue better.

#11

20201014_SPI_Comm_Capture.logicdata (4.5 MB)

#12

Hello,

It looks like the MISO and MOSI lines are swapped in the capture. Once we swap these the messages start to make a bit more sense but not completely. The MISO data still doesn’t make complete sense.

You might not have something setup correctly in regards to hardware design. Is the ABCC MISO connected directly to the AVR? Are there any other SPI devices connected to the bus? Have you verified there are not power issues?

It might also be worth verifying the compactcom you are using. Does it work correctly on the starter kit?

Deryck

#13

Why are you thinking that the lines are swapped? The first line is the MOSI line (Host-Controller is Master) (Master Out Slave In). The data in the capture on the labeled MOSI-line is correct for the Host-Controller. The second line is the MISO line (CompactCommodule is Slave) (Master In Slave Out). The data on the labeled MISO-line is the answer of the M40 module. This makes sense for me, or am I wrong?

Unbenannt
Unbenannt958×228 30.9 KB

No, because the AVR is a 5V-system and the anybus M40-module is a 3,3V -system. I used well selected lvl-shifters between these two systems:

Just the programmer for the AVR. But I get the same results if I disconnect the programmer.

Not really. But I will check that tomorrow. At the moment I use the 3,3V-Supply from the starterkit-board.

It worked correctly with the starterkit yes. But I do not know if it uses the SPI for communication too. The communication from the host-controller to the M40 over the serial communication works fine. So if the starterkit does not use the SPI we do not know more about the correct functionality of the SPI-Interface of the M40-module.

#15

Hello,

We were only speculating on the MISO, MOSI this could just as likely be wrong. We are not seeing enough valid data to say for sure.

Can you provide more details on your setup? Right now I am wondering if there is some kind of hardware related issue. Using the 3.3v from the starter kit could be of concern and would not be recommended. It would be fine to use the breakout board to help with connections but not the starterkit in conjunction with another host.

How confident are you that the signals logged with the Saleae device? I wonder if you are picking up noise or the clock transition is to slow. What side of the level shifters are you taking the captures from? I would recommend taking them from the 3.3v side.

Deryck

#16

I am a little bit confused: I can make the record through the logic analyzer longer. But I think this would not help. The only thing I know is that the Frame showed on the MOSI-line is exactly what is described in the Software-Guide (hms-hmsi-216-125) Chapter 6 page 37. Also the CRC is correct.

I think there is a little misunderstanding. The breakout-board is NOT mounted/connected with the starterkit-board. I use the starterkit-board only for power supply of the M40-Module on the breakout-board. I used some external wires from the 3,3V-Supply of the starterkit-board and connect them to the external power-supply inputs on the breakout-board. To summarize the situation with the communication of the boards: The starterkit-Board and the breakout-board have no physical connection except the power supply. Only the AVR (host) has a connnection to the breakout-board with the M40 module. Of course to make communication physically possible, the ground of the Starterkit-board and the ground of the host are physically connected.

I have drawn a little “quick and dirty” schematic to maybe clarify the situation:

Unbenannt1
Unbenannt11016×568 5.91 KB

I do not understand this question? What are you meaning exactly?

I checked the signals on these lines with an oscilloscope. The “eye diagrams” of the levels seems to be very good. especially for lower clockfrequencies of the SPI-Interface of the host. But as I said, lowering the clock-frequency did not changed the situation of the SPI-communication.

This is exactly the side I recorded on the logic analyzer.

Best regards
zorakon

#17

Hello,
Are you sure you are not picking up any noise could have any thing else that could be causing issue with the connection?

Have you tested SPI with the starter kit? This should only require you to setup a SPI transport provider with the starter kit.

Another thing worth verifying is if the reset pin is kept low once power is being applied to the ABCC. If this isn’t happening the device could be in an undefined state. Using a external pulldown on the aBCC is required since pulling down with a microcontroller can not be guaranteed. Are you meeting the criteria mentioned in section 3.2.7 of the Hardware design guide?

Deryck

#18

I can never 100% be sure, but the setup consists only of a AVR, the starterkit-board, the extension board, the level-shifters and the M40-module. Further more we got the capture from the SPI-lines. For example the MOSI-line. The whole data of every frame is 100% in compliance with the definition in the documentation. The “eye-diagramms” are perfectly on both lines. A speed down of the SPI-clock does not help. The data on the MISO is the most of the time equal to the transmissions before. The only thing which is not correct seems to me the crc coming from the module.

I searched a lot on the hms-website, but I can not find a any documentation about a example implementation, which only uses the starterkit-board and the M40-Module. So the answer to this question is: no I did not tested it yet. But I am really interested how I can implement some kind of example-setup just to check if the SPI of the module is working correctly. Maybe you can post or send me some kind of manual to do this?

I already checked this. This works correctly.

Of course I use a external pull down on this wire. I have read this chapter of the Design guide. I have also checked the voltage level of the 3,3V power supply during startup and normal operation. Everything is ok. But as I said in some posts before, everything works fine if I just change the define ABCC_CFG_ABCC_OP_MODE_40 from ABP_OP_MODE_SPI to ABP_OP_MODE_SERIAL_115_2 in the generic-driver which changes the communication from SPI to serial 115,2kbps. So this gives me confident that the management of power supply, reset and setup-procedure is configured correctly.

#19

Hello,

Discussing this with a colleague our best guess, as I was pointing out earlier, is there is that something is not setting up the Compactcom correctly and this is possibly a hardware configuration issue. It is difficult to say what. As you point out the messages on the MPSI line looks correct but the compact com is not responding as we expect.

Using SPI with the starter kit only requires you to change the transport provider selected.


You might need to change the speed of the SPI connection to ensure you can capture it with Saleae device. This can be updated in abcc_sys_adapt.c line 511. I would recommend 6000000 or 3000000.

Deryck .

.

#20

Ok I understand your point now. So you mean that the hole MISO-data does not match your expectations? How does normally the first MISO-data looks like? Do you have an example?

Ah this seems to be the windows-application for visual studio, am I right? So I first of all have to install visual studio and compile the application or does a compiled version of the program exists? If not, I will try this on Monday.

Ok, I will check the hole wiring of the hardware on monday, too (again), maybe there is something missing as you mentioned. Does the module maybe acts unexpectly if I left the pins D0 to D7 and also A0-A7 open and do not connect them to GND as shown in Appendix A.6 (SPI and Serial) in the HMSI-216-126 M40 Hardware Design Guide? Because that is what I did.

#21

Hi @zorakon,

Here is a capture of the starter kit using spi.2 MHz, 200 M Samples [2].logicdata (1.1 MB)

The windows application does need to be compiled in Visual Studio we don’t have any precompiled versions available.

While I wouldn’t necessarily expect it to leaving those floating could be causing issues. It would be best to remove the possibility.

Deryck

#22

I have now connected everything exactly like in the picture in Appendix A.6 (SPI and Serial) in the HMSI216-126 M40 Hardware Design Guide. The only difference between this picture and my hardware configuration are the level shifters between the module and the AVR. But I still get the same results.

As I said I checked the hole wiring of the hardware again. Everything is connected as expected.

[quote=“zorakon, post:20, topic:67398”]

Due to some time-problems at work I would only be able to check this application tomorrow on Tuesday.

One thing I have recognized while trying to compare my transmission-capture with yours is, that the answered CRC of the module in my capture follows a regularly order. And every restart of the module the CRC on the MISO starts this crc-order from the beginning. Interesting I guess. (For example: I can find on every capture after restart some transmission blocks with the crc answered on the MISO 0x00100840) So because of the reason that these bytes were not completely random, I would like to say that this data can not only be noises.

I have also checked the possibility that the module is maybe in the wrong operating mode because of the wrong signals on the OM-pins. But only with the correct combination for the SPI-Mode I got data on the MISO.

Another question I have is, where I can download the newest firmware for the M40 module? I tried to find it on the hms website.