AM2432: Problem with acyclic data in Profinet

Hi Andrea,

Thank you for asking your query. We would need some additional information to completely understand the issue in detail. Could you please answer the following questions for us to get a better clarity on the cause of this issue?

1. On which slot/subslot is the submodule inserted?
2. What is the record index? Could you also share the wireshark logs showing the read requests that are not responded
3. Could you share the overall device configuration?

Best Regards,
Laxman

Hi Laxman,

thank you for your response.

The submodule is inserted in slot 2 in subslot 1, but the behavior does not change by inserting the module in other slots (while the subslot is fixed at 1).
The read requests are to slot 0, subslot 1 and the record index I use as a test is 0x2004, but the behavior does not change using other values for the record index. I expect that when I send the acyclic read request the stack will at least call the PN_APP_IOD_cbRecordRead callback as in the demo, but this does not happen.
Similarly, using a submodule with smaller length and moving it to different slots and subslots or using different index records does not change the behavior and asynchronous requests always work.

I have attached an example of Wireshark logs when the request is unanswered, and an example when it is answered using a smaller length module. The case when nca_server_too_busy is answered is rarer and I cannot reproduce it at the moment.

I also attach the device configuration used in the sysconfig of the R5FS0-0 core running the application with Profinet.

/**
 * These arguments were used when this file was generated. They will be automatically applied on subsequent loads
 * via the GUI or CLI. Run CLI with '--help' for additional information on how to override these arguments.
 * @cliArgs --device "AM243x_ALV_beta" --package "ALV" --part "ALV" --context "r5fss0-0" --product "INDUSTRIAL_COMMUNICATIONS_SDK_AM243x@09.02.00"
 * @versions {"tool":"1.20.0+3587"}
 */

/**
 * Import the modules used in this configuration.
 */
const flash       = scripting.addModule("/board/flash/flash", {}, false);
const flash1      = flash.addInstance();
const crc         = scripting.addModule("/drivers/crc/crc", {}, false);
const crc1        = crc.addInstance();
const gpio        = scripting.addModule("/drivers/gpio/gpio", {}, false);
const gpio1       = gpio.addInstance();
const gpio2       = gpio.addInstance();
const gpio3       = gpio.addInstance();
const gpio4       = gpio.addInstance();
const gpio5       = gpio.addInstance();
const gpio6       = gpio.addInstance();
const gpio7       = gpio.addInstance();
const ipc         = scripting.addModule("/drivers/ipc/ipc");
const pruicss     = scripting.addModule("/drivers/pruicss/pruicss", {}, false);
const pruicss1    = pruicss.addInstance();
const profinet    = scripting.addModule("/industrial_comms/profinet/profinet", {}, false);
const profinet1   = profinet.addInstance();
const debug_log   = scripting.addModule("/kernel/dpl/debug_log");
const mpu_armv7   = scripting.addModule("/kernel/dpl/mpu_armv7", {}, false);
const mpu_armv71  = mpu_armv7.addInstance();
const mpu_armv72  = mpu_armv7.addInstance();
const mpu_armv73  = mpu_armv7.addInstance();
const mpu_armv74  = mpu_armv7.addInstance();
const mpu_armv75  = mpu_armv7.addInstance();
const mpu_armv76  = mpu_armv7.addInstance();
const mpu_armv77  = mpu_armv7.addInstance();
const mpu_armv78  = mpu_armv7.addInstance();
const mpu_armv79  = mpu_armv7.addInstance();
const mpu_armv710 = mpu_armv7.addInstance();
const mpu_armv711 = mpu_armv7.addInstance();
const mpu_armv712 = mpu_armv7.addInstance();
const mpu_armv713 = mpu_armv7.addInstance();
const mpu_armv714 = mpu_armv7.addInstance();
const mpu_armv715 = mpu_armv7.addInstance();
const timer       = scripting.addModule("/kernel/dpl/timer", {}, false);
const timer1      = timer.addInstance();
const timer2      = timer.addInstance();

/**
 * Write custom configuration values to the imported modules.
 */
flash1.$name                         = "CONFIG_FLASH0";
flash1.peripheralDriver.$name        = "CONFIG_OSPI0";
flash1.peripheralDriver.OSPI.$assign = "OSPI0";

crc1.$name = "CONFIG_CRC0";

gpio1.$name          = "ETH_100BT1_EN";
gpio1.pinDir         = "OUTPUT";
gpio1.defaultValue   = "1";
gpio1.GPIO_n.$assign = "PRG1_PRU1_GPO18";

gpio2.$name          = "ETH_100BT1_RST_N";
gpio2.pinDir         = "OUTPUT";
gpio2.GPIO_n.$assign = "PRG1_PRU1_GPO16";

gpio3.$name          = "ETH_100BTX_RST_N";
gpio3.pinDir         = "OUTPUT";
gpio3.GPIO_n.$assign = "PRG0_PRU0_GPO18";

gpio4.$name          = "ETH_100BTX_RMII";
gpio4.pinDir         = "OUTPUT";
gpio4.GPIO_n.$assign = "PRG1_PRU1_GPO19";

gpio5.$name          = "ETH_100BTX_INT";
gpio5.pinDir         = "OUTPUT";
gpio5.GPIO_n.$assign = "PRG0_PRU0_GPO19";

gpio6.$name          = "PRG1_MDIO0_MDC";
gpio6.GPIO_n.$assign = "PRG1_MDIO0_MDC";

gpio7.$name          = "PRG1_MDIO0_MDIO";
gpio7.GPIO_n.$assign = "PRG1_MDIO0_MDIO";

ipc.r5fss0_1     = "NONE";
ipc.r5fss1_1     = "NONE";
ipc.m4fss0_0     = "notify";
ipc.vringMsgSize = 512;

profinet1.$name                                = "CONFIG_PROFINET0";
profinet1.instance                             = "ICSSG0";
profinet1.phyAddr0                             = 1;
profinet1.phyAddr1                             = 2;
profinet1.icss_emac[0].$name                   = "CONFIG_ICSS_EMAC0";
profinet1.icss_emac[0].mode                    = scripting.forceWrite("SWITCH");
profinet1.icss_emac[0].phyToMacInterfaceMode   = scripting.forceWrite("MII");
profinet1.icss_emac[0].learningEnable          = true;
profinet1.icss_emac[0].rxTaskPriority          = 28;
profinet1.icss_emac[0].txTaskPriority          = 28;
profinet1.ethphy1[0].mdioManualModeLinkPolling = scripting.forceWrite("Polling");
profinet1.ethphy1[0].$name                     = "CONFIG_100BTX";
profinet1.ethphy1[0].customDeviceName          = "DP83826E";
profinet1.ethphy1[0].name                      = "CUSTOM";
profinet1.ethphy2[0].mdioManualModeLinkPolling = scripting.forceWrite("Polling");
profinet1.ethphy2[0].$name                     = "CONFIG_TJA1101";
profinet1.ethphy2[0].customDeviceName          = "tja1101";
profinet1.ethphy2[0].name                      = "CUSTOM";

pruicss1.$name                           = "CONFIG_PRU_ICSS0";
profinet1.icss                           = pruicss1;
pruicss1.AdditionalICSSSettings[0].$name = "CONFIG_PRU_ICSS_IO0";

debug_log.enableUartLog            = true;
debug_log.enableCssLog             = false;
debug_log.enableSharedMemLog       = true;
debug_log.enableSharedMemLogReader = true;
debug_log.uartLog.$name            = "CONFIG_UART_CONSOLE";
debug_log.uartLog.UART.$assign     = "USART0";

const uart_v0_template  = scripting.addModule("/drivers/uart/v0/uart_v0_template", {}, false);
const uart_v0_template1 = uart_v0_template.addInstance({}, false);
uart_v0_template1.$name = "drivers_uart_v0_uart_v0_template0";
debug_log.uartLog.child = uart_v0_template1;

mpu_armv71.$name             = "CONFIG_MPU_REGION0";
mpu_armv71.allowExecute      = false;
mpu_armv71.attributes        = "Device";
mpu_armv71.accessPermissions = "Supervisor RD+WR, User RD";
mpu_armv71.size              = 31;

mpu_armv72.$name             = "CONFIG_MPU_REGION1";
mpu_armv72.accessPermissions = "Supervisor RD+WR, User RD";
mpu_armv72.size              = 15;

mpu_armv73.$name             = "CONFIG_MPU_REGION2";
mpu_armv73.baseAddr          = 0x41010000;
mpu_armv73.size              = 15;
mpu_armv73.accessPermissions = "Supervisor RD+WR, User RD";

mpu_armv74.baseAddr          = 0x70000000;
mpu_armv74.size              = 21;
mpu_armv74.accessPermissions = "Supervisor RD+WR, User RD";
mpu_armv74.$name             = "CONFIG_MPU_REGION3_SRAM";

mpu_armv75.baseAddr   = 0x80000000;
mpu_armv75.size       = 31;
mpu_armv75.attributes = "NonCached";
mpu_armv75.$name      = "CONFIG_MPU_REGION4_DDR";

mpu_armv76.baseAddr = 0x80000000;
mpu_armv76.$name    = "CONFIG_MPU_REGION5_DDR_ICSS";
mpu_armv76.size     = 25;

mpu_armv77.attributes = "NonCached";
mpu_armv77.$name      = "CONFIG_MPU_REGION6_DDR_DATA";
mpu_armv77.size       = 20;
mpu_armv77.baseAddr   = 0x83800000;

mpu_armv78.size       = 20;
mpu_armv78.attributes = "NonCached";
mpu_armv78.$name      = "CONFIG_MPU_REGION7_DDR_BSS";
mpu_armv78.baseAddr   = 0x83900000;

mpu_armv79.attributes = "NonCached";
mpu_armv79.$name      = "CONFIG_MPU_REGION8_DDR_PNIP";
mpu_armv79.baseAddr   = 0x82000000;
mpu_armv79.size       = 23;

mpu_armv710.$name    = "CONFIG_MPU_REGION3_DDR_HEAP";
mpu_armv710.size     = 23;
mpu_armv710.baseAddr = 0x83000000;

mpu_armv711.$name      = "CONFIG_MPU_REGION3";
mpu_armv711.baseAddr   = 0x70000000;
mpu_armv711.size       = 16;
mpu_armv711.attributes = "Cached+Sharable";

mpu_armv712.$name        = "CONFIG_MPU_PRU_ICSS";
mpu_armv712.baseAddr     = 0x30080000;
mpu_armv712.size         = 19;
mpu_armv712.attributes   = "Device";
mpu_armv712.allowExecute = false;

mpu_armv713.$name        = "CONFIG_MPU_REGION12";
mpu_armv713.baseAddr     = 0x88000000;
mpu_armv713.size         = 26;
mpu_armv713.attributes   = "NonCached";
mpu_armv713.allowExecute = false;

mpu_armv714.$name        = "CONFIG_MPU_REGION13";
mpu_armv714.baseAddr     = 0x8C000000;
mpu_armv714.size         = 13;
mpu_armv714.attributes   = "NonCached";
mpu_armv714.allowExecute = false;

mpu_armv715.$name        = "CONFIG_MPU_REGION14";
mpu_armv715.baseAddr     = 0x701D0000;
mpu_armv715.size         = 16;
mpu_armv715.attributes   = "NonCached";
mpu_armv715.allowExecute = false;

timer1.$name         = "CONFIG_TIMER0";
timer1.startTimer    = true;
timer1.timerCallback = "OSAL_FREERTOS_callbackTimer";
timer1.TIMER.$assign = "DMTIMER0";

timer2.$name         = "CONFIG_TIMER1";
timer2.usecPerTick   = 125;
timer2.timerCallback = "PND_EDDP_IrqSendClock";
timer2.TIMER.$assign = "DMTIMER1";

/**
 * Pinmux solution for unlocked pins/peripherals. This ensures that minor changes to the automatic solver in a future
 * version of the tool will not impact the pinmux you originally saw.  These lines can be completely deleted in order to
 * re-solve from scratch.
 */
flash1.peripheralDriver.OSPI.CLK.$suggestSolution          = "OSPI0_CLK";
flash1.peripheralDriver.OSPI.CSn0.$suggestSolution         = "OSPI0_CSn0";
flash1.peripheralDriver.OSPI.DQS.$suggestSolution          = "OSPI0_DQS";
flash1.peripheralDriver.OSPI.D7.$suggestSolution           = "OSPI0_D7";
flash1.peripheralDriver.OSPI.D6.$suggestSolution           = "OSPI0_D6";
flash1.peripheralDriver.OSPI.D5.$suggestSolution           = "OSPI0_D5";
flash1.peripheralDriver.OSPI.D4.$suggestSolution           = "OSPI0_D4";
flash1.peripheralDriver.OSPI.D3.$suggestSolution           = "OSPI0_D3";
flash1.peripheralDriver.OSPI.D2.$suggestSolution           = "OSPI0_D2";
flash1.peripheralDriver.OSPI.D1.$suggestSolution           = "OSPI0_D1";
flash1.peripheralDriver.OSPI.D0.$suggestSolution           = "OSPI0_D0";
profinet1.PRU_ICSSG0_MDIO.$suggestSolution                 = "PRU_ICSSG0_MDIO0";
profinet1.PRU_ICSSG0_MDIO.MDC.$suggestSolution             = "PRG0_MDIO0_MDC";
profinet1.PRU_ICSSG0_MDIO.MDIO.$suggestSolution            = "PRG0_MDIO0_MDIO";
profinet1.PRU_ICSSG0_MII_G_RT.$suggestSolution             = "PRU_ICSSG0_MII_G_RT";
profinet1.PRU_ICSSG0_MII_G_RT.MII0_RXD0.$suggestSolution   = "PRG0_PRU0_GPO0";
profinet1.PRU_ICSSG0_MII_G_RT.MII0_RXD1.$suggestSolution   = "PRG0_PRU0_GPO1";
profinet1.PRU_ICSSG0_MII_G_RT.MII0_RXD2.$suggestSolution   = "PRG0_PRU0_GPO2";
profinet1.PRU_ICSSG0_MII_G_RT.MII0_RXD3.$suggestSolution   = "PRG0_PRU0_GPO3";
profinet1.PRU_ICSSG0_MII_G_RT.MII0_RXDV.$suggestSolution   = "PRG0_PRU0_GPO4";
profinet1.PRU_ICSSG0_MII_G_RT.MII0_RXER.$suggestSolution   = "PRG0_PRU0_GPO5";
profinet1.PRU_ICSSG0_MII_G_RT.MII0_TXD0.$suggestSolution   = "PRG0_PRU0_GPO11";
profinet1.PRU_ICSSG0_MII_G_RT.MII0_TXD1.$suggestSolution   = "PRG0_PRU0_GPO12";
profinet1.PRU_ICSSG0_MII_G_RT.MII0_TXD2.$suggestSolution   = "PRG0_PRU0_GPO13";
profinet1.PRU_ICSSG0_MII_G_RT.MII0_TXD3.$suggestSolution   = "PRG0_PRU0_GPO14";
profinet1.PRU_ICSSG0_MII_G_RT.MII0_TXEN.$suggestSolution   = "PRG0_PRU0_GPO15";
profinet1.PRU_ICSSG0_MII_G_RT.MII1_RXD0.$suggestSolution   = "PRG0_PRU1_GPO0";
profinet1.PRU_ICSSG0_MII_G_RT.MII1_RXD1.$suggestSolution   = "PRG0_PRU1_GPO1";
profinet1.PRU_ICSSG0_MII_G_RT.MII1_RXD2.$suggestSolution   = "PRG0_PRU1_GPO2";
profinet1.PRU_ICSSG0_MII_G_RT.MII1_RXD3.$suggestSolution   = "PRG0_PRU1_GPO3";
profinet1.PRU_ICSSG0_MII_G_RT.MII1_RXDV.$suggestSolution   = "PRG0_PRU1_GPO4";
profinet1.PRU_ICSSG0_MII_G_RT.MII1_RXER.$suggestSolution   = "PRG0_PRU1_GPO5";
profinet1.PRU_ICSSG0_MII_G_RT.MII1_TXD0.$suggestSolution   = "PRG0_PRU1_GPO11";
profinet1.PRU_ICSSG0_MII_G_RT.MII1_TXD1.$suggestSolution   = "PRG0_PRU1_GPO12";
profinet1.PRU_ICSSG0_MII_G_RT.MII1_TXD2.$suggestSolution   = "PRG0_PRU1_GPO13";
profinet1.PRU_ICSSG0_MII_G_RT.MII1_TXD3.$suggestSolution   = "PRG0_PRU1_GPO14";
profinet1.PRU_ICSSG0_MII_G_RT.MII1_TXEN.$suggestSolution   = "PRG0_PRU1_GPO15";
profinet1.PRU_ICSSG0_MII_G_RT.MII_MR0_CLK.$suggestSolution = "PRG0_PRU0_GPO6";
profinet1.PRU_ICSSG0_MII_G_RT.MII_MR1_CLK.$suggestSolution = "PRG0_PRU1_GPO6";
profinet1.PRU_ICSSG0_MII_G_RT.MII_MT0_CLK.$suggestSolution = "PRG0_PRU0_GPO16";
profinet1.PRU_ICSSG0_MII_G_RT.MII_MT1_CLK.$suggestSolution = "PRG0_PRU1_GPO16";
debug_log.uartLog.UART.RXD.$suggestSolution                = "UART0_RXD";
debug_log.uartLog.UART.TXD.$suggestSolution                = "UART0_TXD";

Let me know if you need any other information.

Best Regards,
Andrea

Hi Andrea,

 Please expect a delay in response, as the PROFINET stack expert is currently out of office and will be back after two weeks. We will look into the details you have provided and get back to you with our initial analysis on this issue.

Best Regards,
Laxman 

Hi, are there any updates?

I tried to analyze the code and it seems that during executions where I have no response, the stack function pnpb_process_service_requests (and therefore also the functions pnpb_rec_read_write and PNIO_cbf_rec_read) are not called when the acyclic read request is sent.

Furthermore I noticed that sending acyclic write requests (and write requests only) always has responses, regardless of the length of the submodules used.

In addition, if I first send an acyclic read request that has no response and then I send an acyclic write request, a Status Conflict response is returned, followed by three alarm messages and then the connection is closed (without having called my callbacks). I have attached the wireshark logs of this case. Again, this problem happens only when I have inserted submodules with a long length, whereas when I insert submodules with smaller length I can send acyclic read and write requests without problems.

Best Regards,
Andrea

Hi Andrea,

Thank you for providing additional logs to help us expedite the debug process.

Apologies for the delay, the PROFINET stack expert is still on leave for another week. We will be planning to look into this issue by the start of next week and will examine the logs to root cause the issue.

Best Regards,
Laxman

Hi Andrea,

I'll try to reproduce the issue on my side.
Which PLC are you using? can you share the PLC program?

Regards,
Kamil

Hi Kamil,

thank you for your response.

I am using the tool Profinet Master Simulator.

Best regards,

Andrea

Hi, are there any updates?

I created a test version from an old version of the project that was very similar to the demo, and removed everything that was not related to Profinet operation.
I modified the project's sysconfig by putting the Profinet, PRU, ETHPHY and ICSS-EMAC settings back with those used in the demo, while custom PHYs are actually used in the project. I could not directly test it, but I tested a version with the custom PHYs, and the problem occurs.
When only the module 0x30 is inserted in slot 1 (fixed) and no other module are used, asynchronous read and write requests can be made without problems in all executions.
When another module with larger length is also inserted in slot 2, such as the module 0x32 with 56 byte (or even by inserting several smaller modules that together have a length close to 56 bytes) , responses to asynchronous requests often give the problems described in my previous replies. The behavior is not fixed, often the first 2-3 executions work correctly despite the insertion of the module 0x32, but subsequent executions fails.
I have uploaded the project here (I have also included the GSDML used for testing), hoping the problem may be easier to reproduce and correct.

Best regards,

Andrea

Hi, are there any updates?

Best regards,

Andrea

Hi Andrea,

we apologize for the long delay. A very high priority issue came up and we're still working on it. You will get full support on your ticket within a couple of days.

Thanks for understanding.

Kamil 

Hi, thank you for your response.

I add another question regarding another problem I found. Does the Profinet stack require a specific sysconfig configuration (in particular for linker and MPU)? I noticed that when using memory area 0x82800000 in the linker (but I found it by trial and error), then the Profinet stack gets stuck at PN_API_IOD_startup before PRU initialization (in the screenshot, the red line indicates the area where it stops when it is not working). If I correct this the stack works correctly on one board, while using a different board (probably of different revision) it still does not work and to get it working I had to copy the demo configuration of the MPU and linker. It would be useful to know if there are areas of memory to be specifically reserved in linker and MPU so that we can adapt to these limitations but using a custom configuration.

Best regards,

Andrea

Thanks for the feedback, we will get back on this next week.

Hi Andrea,

Let's start from bottom to top, so we deal with this issue first. Would you please share the following:
1. linker.cmd & syscfg files that get the Profinet stack work.
2. linker.cmd & syscfg files that cause the problem.

These files are needed for debugging/regenerating the problem locally.

Thanks.
Kind regards,
Kamil

Hi Kamil, thank you for your response.

I have attached a zip containing the linker and sysconfig files when Profinet get stuck and when it works.

Best regards,

Andrea

Hi Andrea,

I'm trying to replicate your case so I can reproduce the problem on my side. It seems that you're using your own linker script that has some differences from the one generated in our project. Can you please share the files "SharedSectionsLinker.h" and "ParametersBootLinker.h"?

In our case, we're not using address 0x82800000. Would you please send me the two map files as well (working and not working)?

Tahnks.
Kind regards,
Kamil

Hi Kamil,

I think these two files would be unnecessary, they only contain parts of memory shared with core 1 but adding or removing them does not change the problem with Profinet on core 0. The memory address 0x82800000 is an example of an address that I found by trial and error solving the problem the first time, but solving it the second time (where I was not using that address but the problem persisted) the address causing problems was different, and the example attached solves this second case.
Here now I have attached all possible useful files.

Best regards,

Andrea
5141.Profinet.zip

Hi Andrea,

I tried to reproduce the problem on my side using the "not-working" linker script and sysconfig files. I had to modify them a little bit to fit into my system (please find my files attached). I'm not able to see any problem here and Profinet stack seems to work fine.
The differences between your sysconfig and mine:
- I don't use IPC module
- I use ICSSG1 instead of ICSSG0
- I use the AM243_EVM default DP83869 PHYs instead of the ones you're using
- I disables Ethernet-related GPIO pins 
- I added EEPROM module to fit into an optional need in the stack version I'm using here (not needed in your case)
- I added some LED instances to fit into an optional need in the stack version I'm using here (not needed in your case)

By looking at this result, I'm suspecting that there's something wrong at the Ethernet level. Can you please try to use the default PHYs with ICSSG1 and tell me what happens?

Thanks.
Kind regards,
Kamilconfig_v1.zip

Hi Kamil,

thank you for your response.
On my module it is mandatory to use the custom physical drivers and ICSSG0.
I got myself an AM64x EVM and my code works perfectly on that device, regardless of the linker and MPU configuration with sysconfig (and even using the ICSSG0 and custom drivers, it simply does the map part and then gives errors on PRU_PHY_detect, however at least it gets to execute that part of the code and it doesn't get stuck before) .
However, I noticed on my module that the output part " Initializing PRU instance..." is not printed at all, so the APP_pruInit() function is not called either. Is there anything that would block the invocation of that function on the profinet tasks in the library? Also the behavior is very strange, because on my module the first execution always works, from the next one onwards this problem appears and to run it correctly again you have to wait a few minutes and then only the first execution restarts correctly.
Is there anything else that would be helpful to identify the problem?

And I have another question, looking at the Profinet example project it seems that the sysconfig MPU areas do not match the areas used in the linker. For example, DDR_PERIF, RXTX, HEAP areas are defined in the sysconfig at 0x80600000 onwards but then in the linker they are not used. The DDR_BSS area is defined in the sysconfig at 0x80300000 for 1 MB, but then the .bss part in the linker is assigned to DATA_MEM at 0x8040000. Why are there all these discrepancies between the two files?

Best regards,

Andrea

Hi Andrea,

I'm currently preparing a binary that you can use to provide us with some log info. In the meantime, would you please send me the MAC address assigned to your Ethernet interface?

Thanks.
Kind regards,
Kamil

Hi Kamil,

thank you for your response. I usually use the MAC address AC:D3:64:00:00:00, but it shouldn't be a problem to use another one.

Best regards,

Andrea

Hello Andrea,

would you please contact me on the following Email address: "k-alkhouri@ti.com". I would like to share a binary with you.

Thanks.
Kind regards,
Kamil

Hi Kamil,

I just sent you an email.

Thank you,

Andrea

Hi Kamil,

thanks to your support I found out that this last bug seems to be fixed in version 9.02.15.
The bug on acyclic data, however, is still present. I noticed that the problem occurs when an initial submodule configuration passed to PN_API_IOD_startup() is specified with several submodules inserted, whereas if only the submodules of slot 0 are passed this does not happen.
In my case, I had to occupy all the 9 slots immediately at the time of the PN_API_IOD_startup() call, because otherwise I would encounter another bug that if the slots are not filled at this time, then on the first connection the output data is always constant at zero, and it is necessary to close the connection and reopen it to get the actual output data. This last bug had also happened to me in the demo, so it should be easily reproducible.
Are these known bug? Let me know if more details are needed.

Thanks.
Kind regards,
Andrea

Hi Kamil,

I add two more issues.
The first one is that I noticed that in the file pn_app_iod_cfg.h it is possible to modify macros that change the behavior of SNMP. I have tried to modify some values (such as PN_API_IOD_SNMP_PORT1_NAME and PN_API_IOD_SNMP_INTERFACE_NAME) but when querying the device with an external tool it seems that the values are fixed constants and those macros are not actually used. Is this normal behavior?
The second is that our team has performed a cybersecurity scan with the tool Nessus, and the two problems in the screen were found. Is it possible to take action on my side to be able to fix them? Or are these problems only fixable by correcting them in the stack?

Thanks.
Kind regards,
Andrea

Hi Andrea,

it's recommended that you open one ticket per question. Would you please do that for your last inquiry?

Regarding the acyclic data issue we will continue to work on it here since it was your first question. But first I would like to organize the final problem description and I need your input if I got anything wrong:

1. Problem only occurs when you insert submodules on slots other than slot 0.
2. Problem only occurs when submodule length is 56 bytes or more, or when the total length of multiple smaller submodules on the same slot is 56 bytes or more
3. Problem only occurs with acyclic record read requests

The link you uploaded your project to is not working. Please send me information regarding your initial submodule configuration, your GSDML file, and a wireshark trace of the problem after you upgraded the SDK.

Thanks!
Kind regards,
Kamil

Hi Kamil,
thank you for your reply. I will open another thread for the other problem.

For the problem on acyclic data I summarize everything I found out:
- I am now using SDK 9.02.15 with AM243x
- I use the tool Profinet Master Simulator
- during configuration at the call to PN_API_IOD_startup() I pass 12 submodules in total (4 in slot 0, the remaining 8 in subslot 1 of slots 1-8). If I pass only the 4 submodules in slot 0 in this step, the problem never happens. I wouldn't care to fill all the slots now and it would be enough to just pass the submodules in slot 0, but if I don't plug them all in this step then at the first connection with the Master the slots that were empty don't respond any data at all
- on the Profinet Master Simulator side I now use my GSDML file and plug a submodule with length 56 bytes in slot 2 subslot 1 (but  the same happens if I plug it in other slots). If in this step I plug a submodule with a smaller length, like 18 bytes, the problem never happens. Cyclic communication  works correctly in every situation
- now I make an acyclic read request (but in the same way with the write request), the request is intercepted correctly in Wireshark, but sometimes the response is never sent and the tool returns error because it exceeds the timeout, and sometimes the nca_server_too_busy response is sent.

So points 1 and 2 are correct. Point 3 is partially correct in the sense that acyclic record write request are also giving problems.

I am attaching the source files, the GSDML used now, and the wireshark traces.

Thank you,

Kind regards,

Andrea

4377.Profinet.zip

Hi,

I have also tested with SDK 09.02.00.18 but the problem is still there. I have attached a version of our project where only the Profinet part is present and the problem still occurs. You have only to correct the ETH PHY and the Profinet settings in Sysconfig, because I cannot test it with the default options. The GSDML file is included.

In order to easily reproduce the problem, if only the Command module 0x30 fixed at slot 1 is inserted, acyclic reads and writes work, and it is visible through the debug messages. If, in addition to the Command module, the Device Status module 0x32, of 56 bytes is inserted in slot 2, no more acyclic responses are received in either read or write.

Let me know if more information is needed.

Thank you,

Kind regards,

Andrea

Titan_Profinet_TI.zip