Hello,
The "Post" button is Greyed out on the HSE Community....
FW V 2.4.
CUST_DEL Lifecycle.
Super User rights.
Customer is saying that Enable / Disable of the MU1 attribute does not take effect until after a Reset. I see this table:
Is this expected behavior? Seems odd to me.
See attached email chain.
OK,
I think that made sense and have not heard back from them so we can close this one.
Thanks
Hi Scott,
Here's my analysis:
Issue:
You are polling Hse_Ip_GetHseStatus(MU1) to decide whether MU1 is enabled/disabled, but those status bits aren’t per‑MU—they’re global and mirrored on all MU instances. So, your loop never converges until you reset, which makes it look like a reset is required.
Fix (minimal):
1) Don't use Hse_Ip_GetHseStatus(MU1) as MU1 enable/disable evidence.
Instead, read back the attribute with GET_ATTR and check muInstances[MU1].muConfig.
2) (Optional) After enabling MU1, init the driver for MU1 (Hse_Ip_Init(MU1, &state1)) and verify by trying to allocate a channel or send a trivial admin request on MU1; after disabling, deinit MU1.
Not: If you use XRDC isolation, ensure host access to MU1 is allowed; HSE doesn’t configure XRDC.
With these changes, MU enable/disable will take effect at runtime (no reset).
Thanks,
Sindhu
Hi,
They say that they cannot run the demo because they don't have a LB.
Attached is a basic project that they say demonstrates the behavior.
I will be looking at it also, but thought perhaps you could see something obvious faster than I can.
Thanks
Hello Scott,
No this is not expected behavior. There must be some other part of the customer's application code that is influencing this behavior.
We can debug it further if they can share their project file. They can also use our DemoApp where we have an example to demonstrate how to enable MU.
Thanks,
Sindhu