RTOS/AM4378: PRP example issue

The RTOS team have been notified. They will respond here.

Hi Marko,

I am seeing pruss_config[0].object is set to prussObjects which is defined as PRUICSS_V1_Object and from

/* PRUICSS objects */

PRUICSS_V1_Object prussObjects[PRUICCSS_INSTANCE_MAX-1];

/* PRUICSS configuration structure */

PRUICSS_Config pruss_config[PRUICCSS_INSTANCE_MAX] = {

   {

       &prussObjects[0],

       &prussInitCfg[0]

   },

Also

typedef struct PRUICSS_V1_Object_s

{

   uint32_t            pruicss_version;

   int32_t                 instance;         /* PRUICSS write semaphore*/

   void*               pruBinBuff[2];         /* Buffer data pointer */

   uint32_t        buffLen[2];

   PRUICSS_IrqFunMap   pruEvntOutFnMapArray[PRUICSS_MAX_WAIT_EVENTS];

}PRUICSS_V1_Object;

I don't quite follow you - address to pruss0 object is broken. Can you elaborate or do you have a crash log to illustrate the problem?

Thanks,
Garrett

Hi Garrett,

please flow my points and steps:

1.) int main() ->

#if !defined SOC_AM335x
    PRUICSS_socGetInitCfg(&pruss_config);
#endif

pruss_config is defined in pruicss_soc.c.

2.) I add some variables and stuff to program so probably addresses will be different, but try to debug step-by-step and check struct array pruss_config.
2.a) put breakpoint to :

    *cfg = &pruss_config[0];

line 785 - function PRUICSS_socGetInitCfg() in pruicss_drv.c
2.b) Check address of pruss_config. In my case is 0x800A7E18
2.c) Check pruss_config[0].object value. In my case is 0x8010E154
2.d) Step to:

return PRUICSS_RETURN_SUCCESS;

2.e)Check value of  pruss_config[0].object... must be the same as &pruss_config[0]. Here is pruss_config[0].object value (address to object) broken, because *cfg is also pruss_config[0].
So if anyone wants to use ICSS0 will get exception cuse *.object is broken!

2.f) this is bug?

Best regards, Mare

Garrett,

correct!

Regards, Mare

Mare,

I have found an internal record about the bug. This has been resolved in upcoming HSR/PRP 1.0.3 release. Thank you!

Regards,
Garrett

Garrett,
It is my pleasure to cooperate.
I also suggest use of SysMin instead of SysStd in example. SysStd with time consuming operations make emac driver unstable on init. This was mentioned in my previews posts about PRP issues.
Thank you!

Mare,

Yes, using SysMin instead of SysStd is in our plan as well and we have a dedicated ticket to track the change.

Regards,
Garrett