‎2019-11-11 12:18 PM
I simply can't figure out how to generate this pulse with my STEVAL-IOM001V1 board. Even the supplied code (en.stsw-iom001) doesn't make me any wiser.
‎2020-03-26 09:36 AM
Then you might have triggered successfully the WURQ.
Now, the communication process is quite tedious as well. You won't get any data from the sensor if you do not switch it from STARTUP mode to OPERATE mode and if you don't ask for it.
The first message you should send should read the "MinCycleTime" as stated by the specs. This message is built with 2 UART bytes, one MC byte (A.1.2) and one CKT byte (A.1.3).
Make sure that when you're sending to the device you are pulling the ENCQ line to high with a GPIO and when you are done transmitting pull it to low and read the response. The response should be 2 bytes as well as in Figure A.5 with [OD, CKS]. In OD you will find the MinCycleTime value which should be 2.7ms for your sensor.
Once you are able to get that response, you'll have to implement the IO-Link initialization sequence of messages that puts the sensor in operating mode and which is described in Figure 79 of the specs (forget about the T11 transition in that diagram which works only for legacy 1.0 IO-Link devices).
Hope this helps
‎2020-03-29 08:27 AM
I thought that after the wakeup request I need to set the COM mode to communicate with the device. From what I read I am supposed to go through all the COMs from COM3 to COM2 to COM1 and send a message on each COM setting until I get a response from the sensor. If I get a response I know that the COM used is the COM for the specific sensor (in my case it should be COM2).
After making a few adjustments to the ST stack (specifically regarding the UART packet structure) it seems that I am getting some kind of a response from the sensor.
Now, you said my first message should be reading the minimum cycle time, is this the message that I am supposed to send after selecting each COM?
Because this is what I tried and this is the result:
The first byte I sent is (MC) = 0xA2
The second byte I send is (CKT) = 0x00
I performed a bitwise XOR between 0x52 (SEED) and 0xA2 (MC) which resulted in the 8 bit checksum = 0xF0
And then I performed the compression procedure (as described in A.1.6) to turn it to 6 bit checksum = 0x00
The response I got from the sensor is - 0x1b and then 0x2b
I fail to understand how this translates to the minimum cycle time as described in Figure B.2 and Table B.3.
You got any idea what else I'm missing?
Something worth mentioning:
Thanks a lot!!!
‎2020-03-29 09:09 AM
Don't bother going through testing all the COM speeds as you know already yours. This is a specification for generic masters that do not have any prior knowledge of the sensor's specs.
Nice, the sensor's answer is correct. 0x1B = 0011011 = [time base = 00, multiplier = 11011] = 0.1(ms) * 27 = 2.7ms which corresponds to your datasheet.
When I read "MasterCycleTime" (0x01 -> MC = 0xA1) on my sensor I have 3.1ms which is the time I use for the communication loop.
Yes that's normal. HAL_UART_Transmit_IT is non-blocking. I use HAL_UART_Transmit (blocking) to send my UART commands and HAL_UART_Transmit_DMA (non-blocking) to read the response. This allows to better control the timing of the main comm. loop. However, you need to use some sync. flags and the UART rxCallback, triggered once the read on the DMA is finished (void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart)).
‎2020-03-31 12:05 PM
Thanks, you're truly a lifesaver!
I can now communicate with the sensor, I can read and I can write to it =)
I think I properly went through the IO-Link initialization sequence though I am not sure if I'm actually in Operate mode, is there a way to check ?
What I can say is I'm now reading the sensor's "Process data output" parameter (0xCA) and in response I am getting 5 bytes which I think I figured out what each one of them mean - process data output | signal quality | process value byte 1 | process value byte 2 | checksum.
This is the data I am transmitting to read this parameter:
dataBuffer[0] = 0xCA; // M.C octet
dataBuffer[1] = 0xB6; // CKT octet = type + checksum
What I still don't understand is the M-Sequence types mechanism, I am using type_2 here.
If I understand correctly I am supposed to use type_2_V but according to Table A.10 this means setting the M-Sequence part in the CKT octet to the value of '4' and the M-Sequence part consists of only 2 bits (Figure A.2).
What am I missing here ? o.O
Also, is there a way to make the sensor send me its process data without me polling for it ?
As far as I can tell in Operate mode the sensor is supposed to cyclically send me data but I don't see it happening...
Once again, thanks for you help =)
‎2020-03-31 12:31 PM
Hi @LHaim​. Can I trouble you to post the WURQ part of your coding?
I have a STEVAL-IPD0004V1 board but I failed to communicate with my sensor. I am able to successfully configure the L6360's LED through I2C.
But when I sent 0xA2,0x00 through the UART (these two packets are sent successfully as I can see it through my oscciloscope) but I get no response from my sensor.
Thank you. And congrats on your success.
‎2020-04-01 03:33 AM
Sure, this is the code part that's related to the wake up sequence:
uint8_t dataBuffer[10] = { 0 };
/* Enable CQ output */
BSP_IOLinkMaster_SetCQOutputEnable(0U ,1U);
/* Enable L+ power supply and after */
/* a delay L+ line of all devices */
BSP_IOLinkMaster_SetLPowerSupply(0U ,1U, 0U);
HAL_Delay(1U);
BSP_IOLinkMaster_SetLPlusEnable(0U ,1U);
/* Perform wakeup sequence */
/* Set configuration register to to push pull */
/* It is required to switch first to off state */
/* Then read the sensors status */
BSP_IOLinkMaster_WriteRegister(L6363_I2C_ADD_0, (uint8_t)L6360_CONFIGURATION, L6360_CONFIGURATION_CQ_OFF);
BSP_IOLinkMaster_WriteRegister(L6363_I2C_ADD_0, (uint8_t)L6360_CONFIGURATION, L6360_CONFIGURATION_CQ_PUSH_PULL);
BSP_IOLinkMaster_GetStatus(L6363_I2C_ADD_0);
HAL_Delay(50);
/* Perform IO Link initialization sequence */
// For FT-10 we need COM2 speed setup
// T4 :Set COM speed to COM_2 (38.4 kbauds)
BSP_IOLinkMaster_SelectComMode(0U, COM_2);
// Read minimum cycle time (part of wake up procedure)
dataBuffer[0] = 0xA2U; // M.C octet = read + page + request miminum cycle time
dataBuffer[1] = 0x00; // CKT octet = type + 0 checksum
checksum = GS_IoLink_CalcChecksum(dataBuffer, 2);
dataBuffer[1] |= checksum;
BSP_IOLinkMaster_SetCQOutputEnable(0U ,1U);
BSP_IOLinkMaster_SendInCqData(0U, dataBuffer[0]); // M.C
BSP_IOLinkMaster_SendInCqData(0U, dataBuffer[1]); // CKT
BSP_IOLinkMaster_SetCQOutputEnable(0U ,0U);
HAL_Delay(1);
This is the CalcChecksum function:
/******************************************************//**
* @brief Calculate checksum for the CKT octet
* @param[in] data the data to calculate the checksum to
* @param[in] numberOfOctets the number of octets to include in calculation
* @retval value = calculated checksum
* @note
**********************************************************/
uint8_t GS_IoLink_CalcChecksum(uint8_t data[], uint8_t numberOfOctets)
{
uint8_t checksum = GS_IOLINK_CHECKSUM_SEED;
for(int i = 0; i < numberOfOctets; i++)
{
checksum ^= data[i];
}
checksum = CalcChecksum6(checksum);
return checksum;
}
This is the CalcChecksum6:
/******************************************************//**
* @brief Calculate checksum 6 for the CKT octet
* @param[in] checksum8 the checksum 8 to compress to checksum 6
* @retval value = calculated checksum 6
* @note
**********************************************************/
uint8_t CalcChecksum6(uint8_t checksum8)
{
uint8_t checksum = 0;
checksum |= (((checksum8 >> 0) & 0x01) ^ ((checksum8 >> 1) & 0x01)) << 0;
checksum |= (((checksum8 >> 2) & 0x01) ^ ((checksum8 >> 3) & 0x01)) << 1;
checksum |= (((checksum8 >> 4) & 0x01) ^ ((checksum8 >> 5) & 0x01)) << 2;
checksum |= (((checksum8 >> 6) & 0x01) ^ ((checksum8 >> 7) & 0x01)) << 3;
checksum |= (((checksum8 >> 0) & 0x01) ^ ((checksum8 >> 2) & 0x01) ^ ((checksum8 >> 4) & 0x01) ^ ((checksum8 >> 6) & 0x01)) << 4;
checksum |= (((checksum8 >> 1) & 0x01) ^ ((checksum8 >> 3) & 0x01) ^ ((checksum8 >> 5) & 0x01) ^ ((checksum8 >> 7) & 0x01)) << 5;
return checksum;
}
Are you using the same stack that I am using?
If so you should know that I changed the UART configuration within the stack (L6360_Board_UartInit) to the following:
uint8_t pinState = L6360_Board_GetEnCQPinState(portId);
pUartHandle->Init.BaudRate = 230400U;
pUartHandle->Init.WordLength = UART_WORDLENGTH_9B; //UART_WORDLENGTH_8B;
pUartHandle->Init.StopBits = UART_STOPBITS_1;
pUartHandle->Init.Parity = UART_PARITY_EVEN; //UART_PARITY_NONE;
pUartHandle->Init.Mode = UART_MODE_TX_RX;
pUartHandle->Init.HwFlowCtl = UART_HWCONTROL_NONE;
pUartHandle->Init.OverSampling = UART_OVERSAMPLING_16;
As you can see I changed to 9 bit length and even parity, the baud will be changed by the stack when you call the BSP_IOLinkMaster_SelectComMode function.
Let me know if it works for you now.
‎2020-04-01 06:24 AM
@LHaim​ Thank you. I am using a different stack.
However, I have found the source of my problem. I did not set the word length to "9 bits" in the UART configuration.
It worked after I correct this and nothing else.
Do you know what is the command to access the "Process Data"? I have been digging into "IO-Link Interface and System - Specification" but there is no clear instruction.
I have been using "Comm Channel = 1" and "Address = 1" but there is not response.
Apart from reading from "Direct Parameter", I can't get the device to perform anything else.
‎2020-04-01 06:28 AM
@SLee.7​
As I stated previously this is the data I am transmitting to read process data:
dataBuffer[0] = 0xCA; // M.C octet
dataBuffer[1] = 0xB6; // CKT octet = type + checksum
Unfortunately this is acyclic reading (did not succeed reading cyclically yet) and in any case this might be sensor specific.
‎2020-04-01 07:02 AM
@LHaim​ This does not work for me as "dataBuffer[0] = 0xCA" has the "Comm Channel" set to "ISDU" and my device does not support "ISDU".
Thanks a lot for your help. I will see if I can come across the information to set up the device cyclically and will update you.
‎2020-04-01 07:34 AM
Ummm...
0xCA = 11001010
Fix me if I'm wrong but, I marked the bits which set the comm channel (Figure A.1) and according to Table A.1 this comm channel is Diagnosis and not ISDU. Are you sure this is the reason it's not working ?
Which device/sensor are you using ?