I am trying to use CANopenNode into a STM32L476 device by using libohiboard as HAL library. In the network, I have: (i) my board that operates as a master and (ii) a commercial node. At startup, the node sends HB message and SYNC message. When my board use
CO_NMT_sendCommand(CO->NMT,CO_NMT_ENTER_OPERATIONAL, 0x0A);
the master starts to send continually the same message without stopping!
With logic analyzer I see this:
Where Channel 0 is the TX pins of the microcontroller, and Channel 1 is the RX pin.
I can't understand why the message returns into RX pin immediately! I checked the microcontroller configuration and the loopback mode is OFF.
Thanks
Looks like normal CAN operation - all messages are immediately echoed back while they are sent or else bus arbitration wouldn't work. The only difference is the ACK bit which you can see are set on the rx line but not on tx. This bit is filled in by the other CAN node on the bus.
The reason why your node keeps sending the same message doesn't seem related to this.
I don't know how it works on your controller but usually you have to pay attention to send NMT_start_command only when your slave node doesn't return any heartbeat or if the heartbeat value is different than the mode expected (pre operational or operational as an example)
If the slave doesn't return anything there might be multiple reasons:
nothing activated so you have first to set a time using the right SDO
the slave use nodeguarding instead of heartbeat so you have to query first the slave with a message ID: 0x700 + Node ID, DLC: 0
Please let me know if it is not clear or doesn't help
Related
Suppose I have two STM boards with a full duplex SPI connection (one is master, one is slave), and suppose I use HAL_SPI_Transmit() and HAL_SPI_Receive() on each end for the communication.
Suppose further that I want the communication to consist of a series of single-byte command-and-response transactions: master sends command A, slave receives it and then sends response A; master sends command B, slave receives it and then sends response B, and so on.
When the master calls HAL_SPI_Transmit(), the nature of SPI means that while it clocks out the first byte over the MOSI line, it is simultaneously clocking in a byte over the MISO line. The master would then call HAL_SPI_Receive() to furnish clocks for the slave to do the transmitting of its response. My question: What is the result of the master's HAL_SPI_Receive() call? Is it the byte that was simultaneously clocked in during the master's transmit, or is is what the slave transmitted afterwards?
In other words, does the data that is implicitly clocked in during HAL_SPI_Transmit() get "discarded"? I'm thinking it must, because otherwise we should always use the HAL_SPI_TransmitReceive() call and ignore the received part.
(Likewise, when HAL_SPI_Receive() is called, what is clocked OUT, which will be seen on the other end?)
Addendum: Please don't say "Don't use HAL". I'm trying to understand how this works. I can move away from HAL later--for now, I'm a beginner and want to keep it simple. I fully recognize the shortcomings of HAL. Nonetheless, HAL exists and is commonly used.
Yes, if you only use HAL_SPI_Transmit() to send data, the received data at the same clocked event gets discarded.
As an alternative, use HAL_SPI_TransmitReceive() to send data and receive data at the same clock events. You would need to provide two arrays, one that contains data that will be sent, and the other array will be populated when bytes are received at the same clock events.
E.g. if your STM32 SPI Slave wishes to send data to a master when the master plans to send 4 clock bytes to it (master sends 0xFF byte to retrieve a byte from slave), using HAL_SPI_TransmitReceive() will let you send the data you wish to send on one array, and receive all the clocked bytes 0xFF on another array.
I never used HAL_SPI_Receive() before on its own, but the microcontroller that called that function can send any data as long as the clock signals are valid. If you use this function, you should assume on the other microcontroller that the data that gets sent must be ignored. You could also use a logic analyzer to trace the SPI data exchange between two microcontrollers when using HAL_SPI_Transmit() and HAL_SPI_Receive().
I am realizing a scenario of DAG root and DAG node in Contiki NG environment with Sender Based Orchestra while using UDP between nodes.But I have a problem of lack of RX in my Cooja Simulation after enabling Clear Channel Assesment(CCA) in my project-conf.h file. What should I change in my files to solve this problem?
I use one node for DAG root and one node for DAG node(while using the files under Contiki NG namely udp-server.c and udp-client.c). After CCA I have had an error like !dl-miss TXbeforeTX 2800 2120 in the mote output of COOJA. As I get it there was a problem in timing. Therefore, I have changed the CCA offset(default is 1800 us) to 1000 us and apparently it erased the warning. But this approach did not work on lack of RX in especially sender based unicast and EB slotframes. While seeing TX for mentioned slotframes, RX could not be observed. I could see in the mote output that the node tries to send a packet but it is never acknowledged. Also after sometime I have observed that the nodes were leaving the network.
I expect to have a RX slots for EB and Sender based unicast slotframes as well but actual result is I am getting RX just for Broadcast slotframe.
What should I change in my configuration files?
I have a weird problem with multi-master in Modbus TCP/IP. I know that Modbus Serial doesn't support multi master. But when I saw some documents, they said Modbus TCP supports multi master.
I composed three tcp clients as Modbus TCP master and a server as Modbus TCP slave. Each Modbus TCP master requests the Modbus TCP slave to get data at every 2 seconds regularly. And I use Modbus TCP stack for master device, which made by Triangle MicroWorks.
I expected every master could receive data from slave, but actually, one
master only communicated well with slave, other masters could not receive data. They only received a return status "3", which means "MBCHNL_RESP_STATUS_CANCELED".
In this composition, is this behavior right?
I wonder if "multi-master/multiple same request" couldn't be supported by the stack or there are other ways to behave multi-master.
I found an answer for this problem.
In short, masters were too fast and the slave channel was busy. I cannot assure all types of modbus stack doing like this, but it did in that case.
The return message, "MBCHNL_RESP_STATUS_CANCELED", came from the message queue in the TMW stack code, it because there're some code for checking to make sure this is not a duplicate request. So the slave channel couldn't afford to process messages from three masters simultaneously, and then messages of each masters remained in their own queue.
I asked Triangle Microworks same question, I received their opnion last week.
"... You are allowed to have multiple channels(each channel must have a unique ip/port combination).
2 seconds may be too fast for only 1 channel. ... Try changing period to 3 seconds and so on."
I think it is not perfect answer, so I improved logic for requesting as bellow.
- Send per 2 seconds, but if I only received response.
The communication is more fluent than it was. It looks more continuous. Sometimes, masters cannot receive some seconds, but after some seconds, they communicate well again.
I know it is not a perfect answer as well. If I found a better answer, I'll write it again.
Hey guys i've been working on this like 72 hours straight and i can't find the error, i'm working on a PIC16F1719 i'm trying to set 3 peripherials an ADC a I2C Protocol and a USART for comunicating to a BT however the ADC was easy, but i'm having a rough time with the I2C despite the fact i've check the code several times, for some reason when i get the ACK's everything seems OK, but when i go for a lecture on the sensor (MPU6050) nothing shows up but the value i putted last time on the buffer, any ideas why this is happening? It's like the buffer doesn't clear itself and i think i can´t clear it through software, thanks.
i2c slave has the ability to lock the bus if the master does not communicate correctly with it (several possible scenarios...)
This is electirically possible since the 2 wires are wired-and, that means if any slave pulls the clock (for example) down, and keeps it that way, the bus is locked.
Always check first the values on both wires (using scope or dvm), if '0' it means bus locked.
Next test the status register of your i2c controller, it may show arbitration error or something of that sort.
If any of the errors, read the i2c slave part datasheet carefully to check what types of protocol read/write it expects and fix your code.
My recent project requires the use of i2c communication using a single master with multiple slaves. I know that with each data byte (actual data) sent by master,the slave responds with Nack\Ack(1,0).
I am confused that how this Nack and ACK are interpreted. I searched the web but i didn't got clear picture about this. My understanding is something like this.
ACK- I have successfully received the data. Send me more data.
NACK- I haven't received the data.Send again.
Is this something like this or I am wrong.
Please clarify and suggest the right answer.
Thanks
Amit kumar
You really should read the I2C specification here, but briefly, there are two different cases to consider for ACK/NACK:
After sending the slave address: when the I2C master sends the address of the slave to talk to (including the read/write bit), a slave which recognizes its address sends an ACK. This tells the master that the slave it is trying to reach is actually on the bus. If no slave devices recognize the address, the result is a NACK. In this case, the master must abort the request as there is no one to talk to. This is not generally something that can be fixed by retrying.
Within a transfer: after the side reading a byte (master on a receive or slave on a send) receives a byte, it must send an ACK. The major exception is if the receiver is controlling the number of bytes sent, it must send a NACK after the last byte to be sent. For example, on a slave-to-master transfer, the master must send a NACK just before sending a STOP condition to end the transfer. (This is required by the spec.)
It may also be that the receiver can send a NACK if there is an error; I don't remember if this is allowed by the spec.
But the bottom line is that a NACK either indicates a fatal condition which cannot be retried or is simply an indication of the end of a transfer.
BTW, the case where a receiving device needs more time to process is never indicated by a NACK. Instead, a slave device either does "clock stretching" (or the master simply delays generating the clock) or it uses a higher-layer protocol to request retrying.
Edit 6/8/19: As pointed out by #DavidLedger, there are I2C flash devices that use NACK to indicate that the flash is internally busy (e.g. completing a write operation). I went back to the I2C standard (see above) and found the following:
There are five conditions that lead to the generation of a NACK:
No receiver is present on the bus with the transmitted address so there is no device to respond with an acknowledge.
The receiver is unable to receive or transmit because it is performing some real-time function and is not ready to start
communication with the master.
During the transfer, the receiver gets data or commands that it does not understand.
During the transfer, the receiver cannot receive any more data bytes.
A master-receiver must signal the end of the transfer to the slave transmitter.
Therefore, these NACK conditions are valid per the standard.
Short delays, particularly within a single operation will normally use clock stretching but longer delays, particularly between operations, as well as invalid operations, my well produce a NACK.
I2C Protocol starts with a start bit followed by the slave address (7 bit address + 1 bit for Read/Write).
After sending the slave address Master releases the data bus(SDA line), put the line in high impedance state leaving it for slave to drive the line.
If address matches the slave address, slave pull the line low for the ACK.
If the line is not pull low by any of the slave, then Master consider it as NACK and sends the Stop bit or repeated start bit in next clock pulse to terminate the or restart the communication.
Besides this the NACK is also sent whenever receiver is not able to communicate or understand the data.
NACK is also used by master (receiver) to terminate the read flow once it has all the data followed by stop bit.