Question about the use of osBioChannelOpen() in a multicore build

[Mick92]

Hello,

I would like to use an Ethernet connexion on Core 0 only in my application but I'm faced to an issue on multicore build whereas it works fine on monocore build. A task is dedicated to the network on Core 0 and is in charge to initialize ant to control it. The code of the network task is based on the "net_demo" example.

Basically the first step was to just start the background task on cores 1 to 5 and to keep the application on Core 0. The application is running without any error raised from SmartDSP but there is no activity on the network (I use wireshark tool).

I tryied to modify the example net_demo to do the same and I have the same behaviour. I modified the main() function to execute appInit() only on Core 0:

if (osGetCoreID() == OS_MASTER_CORE){   /* Place any required initialization code within appInit().      Using local variables inside main() is NOT recommended, because      its stack is never restored - osStart() never returns !!! */   status = appInit();   if (status != OS_SUCCESS) OS_ASSERT;}

 and I removed the call to osWaitForAllCores() in appInit() as other cores didn't execute this function.

I found a workaround that consist to initialize Rx/Tx channels on all cores and the issue is no more seen but I don't understand why it is needed to initialize the network on each core? I didn't find any notes about that in the user guide and API reference manual.

Thanks for your help.

Best regards,

Mickaël

[CrasyCat]

Hello

I did get a closer look at this one.

It looks like the UEC device need to be configured on all 6 cores in order for the application to run correctly.

Meaning the code from beginning of appInit down to

      if (osGetCoreID() == osGetMasterCore())

      {

            initArpProxy();

      }

need to be executed on OS_NUM_OF_CORES.

After that UEC can be used on one core only. This does not generate additional issue.

It looks like UEC driver was not designed to support quantities are cores that differ from OS_NUM_OF_CORES.

CrasyCat

[Mick92]

Hello CrasyCat,

Thank you for your feedback. So it confirm our assumption and that mean that configuring the UEC on each cores would be the final solution.

Just one more question, currently our workaround execute the code from the beginning of appInit() to the end of:
    /* Note: this must be called after all the channels have been opened ! */
    osWaitForAllCores();
    if (osGetCoreID() == osGetMasterCore())
    {
        osBioDeviceCtrl(uec_handle, UEC_CMD_ENABLE, NULL);
    }

I disabled the part of code which create interfaces and sockets on core 1 to 5 (you can have a look on the modified file from the net_demo in attachement). Could you confirm if it is correct or should I keep the full configuration of the UEC on core 1 to 5 as you described in your post? My concern is about the visibility of all cores from the network, in our application we would like to have only one entry point, I mean one IP address delivered by a DHCP server.

Thank you for your help.
Best regards,
Mickael

[CrasyCat]

Hello

   Main problem with your implementation is that if someone is pinging IP address 192.169.1.12, 192.169.1.13,

  192.169.1.14, 192.169.1.15 or 192.169.1.16, application will stop respectively on core 2 to 5 because configuration of the

   channel is not consistent.

  You may need to associate another callback function to the receive channel to prevent the application from stopping

   something like

           if (osGetCoreID() == OS_MASTER_CORE) {           
              ch_open_params.callback = etherInput;
            }
            else {
                ch_open_params.callback = etherInputVoid;               
            }

   Problem here is implementation of the etherInputVoid function. You need to make sure all necessary memory is

   released to prevent memory leaks.

  Anyway I would not recommend going this way as the drivers were not designed initially to allow this kind

  of configuration. So you may jump into another issue later on. 

CrasyCat

[Mick92]

Hello CrasyCat,

Ok, thank you a lot for the clarification.

Best regards,

Mickaël

[Mick92]

With the missing file...