I want to use Anybus m40 in a TI processor F28335. I have adapted the system level and it works successfully. The second call to the functionpsReadMessage.psMsg = pnABCC_DrvReadMessage() triggers an interrupt ILLEGAL_ISR. I understand that this question needs to be written in support of TI, but maybe you also have a solution to my problem. I also want to know if you know of successful applications of Anybus with TI processors.
I want to use Anybus m40 in a TI processor F28335. I have adapted the system level and it works successfully. The second call to the function psReadMessage.psMsg = pnABCC_DrvReadMessage(); triggers an interrupt ILLEGAL_ISR. I understand that this question needs to be written in support of texas, but maybe you also have a solution to my problem. I also want to know if you know of successful applications of Anybus m40 with Texas processors.
Hi Ivan,
What are you basing your port on? I believe we have a working example of the host application for the TI C2000 that is shared with the starter kit. If you don’t have the starter kit application you can request it here: Get started with your Anybus CompactCom In-design
Deryck
I found a solution to my problem. I will write about it here, maybe it will help make the driver better. During driver adaptation, I changed the #define ABCC_PORT_DebugPrint(args) since on a TI processor the function printf() does not print the serial port. I have implemented this with the sprintf() and function of printing to the serial port. I found that after the ABCC_PORT_DebugPrint(args) was executed, the function pointer &pnABCC_DrvReadMessage changed. An unused memory area is located at this pointer. in a Texas processor, the instruction 0xFFFF is an illegal interrupt call. First, I deleted everything except one parameter of the ABCC_PORT_DebugPrint(args) and the pointer did not change, then I added one at a time and found out that the function does not change the pointer with 7 parameters. I think that the reason is the lack of processor resources to perform sprintf() operation with a large number of parameters. So I split the output into 2 parts. Then I realized that the problem is in the small buffer length for the sprint() function and this is my big fail. Insufficient length of the buffer in the sprint() function leads to unpredictable results in memory. I would like to draw your attention to the fact that the length of this buffer for the successful output of debug messages must be at least 128 characters. Perhaps this will help someone in the implementation of the driver for processors in which there is no way to output debug information to the serial port through the printf() function.![image|281x500]
(upload://jkBp01ZunK7m82Lj8h5m0r177a0.png)Hi Ivan,
Thanks for the feedback!
Deryck
