K82: Enable user access to SIM

[EugeneHiihtaja]

Hello !

I have some problem when enable clock for I2C0/i2C1 driver when enable clock in SIM module.

AIPS0 is configured to give access with User privileges to SIM module. But CLOCK_EnableClock cause BusFault

when clock is going to be enabled for I20 or (I2C1) interfaces.

From other side, enable clock for CLOCK_EnableClock(kCLOCK_PortB) is not cause any problem.

In function  I2C_MasterInit()

....

/* Enable I2C clock. */
_SYSCALL(PRINTF("AIPS0->PACRJ ( 0x%08lX ) - 0x%08lX\r\n", &AIPS0->PACRJ, AIPS0->PACRJ));

-> AIPS0->PACRJ ( 0x40000054 ) - 0x15115500   // OK

//CLOCK_EnableClock(s_i2cClocks[I2C_GetInstance(base)]); // Original code

clock_ip_name_t clock = s_i2cClocks[I2C_GetInstance(base)]; // Code split for 2 parts for detect root cause
PRINTF("kCLOCK_I2c0 ( 0x%08lX ) - 0x%08lX\r\n", kCLOCK_I2c0, clock);

-> kCLOCK_I2c0 ( 0x10340006 ) - 0x10340006 // API OK !

_SYSCALL(/**/CLOCK_EnableClock(clock)/**/); // OK in privileged mode

CLOCK_EnableClock(kCLOCK_I2c0);

or CLOCK_EnableClock(clock);    // Bus Bault  !!!!

// This macro is used for escalate supervisor privileged 

#define _SYSCALL(CODE) \
{ \
BaseType_t xRunningPrivileged = xPortRaisePrivilege(); \
CODE; \
vPortResetPrivilege(xRunningPrivileged); \
}

It means, access to SIM is enabled with User privileges.

But call CLOCK_EnableClock(clock);  cause Bus Fault

BUT if I call twice  e.g with supervisor privileges and after that with User privileges :

_SYSCALL(/**/CLOCK_EnableClock(clock)/**/);

CLOCK_EnableClock(clock);    // OK ?!!!!!!!!!!!!

It is also work.

Can it be some HW defect when twice call for enable I2C clock is really required ?

Issue is repeatable all the time.

But one call  CLOCK_EnableClock(clock);  should work if SIM can be accessed in User mode.

What can be problem ?

Regards,

Eugene

[EugeneHiihtaja]

Hi Kerry !

Project include RTOS-MPU extension what can't be shared.

Do you have in SDK any example of code what run with user privileges ?

I can try to expand it with those calls.

Regards,

Eugene

[kerryzhou]

Hi Eugene,

   Thank you for your feedback.

   No, I don't have that code.

  So, can you add your code in the official SDK code, which can reproduce the problem, and share it with me?

Have a great day,
Kerry

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[kerryzhou]

Hi Eugene Hiihtaja ,

  Please try this code to open the I2C0 clock in your code:

SIM->SCGC4 |= (1<<6);

 Whether it still have the hardfault or not?

  You said, CLOCK_EnableClock(kCLOCK_PortB)  this code open the portb in the SIM doesn't have problems, it means your SIM should work.

 Anyway, try to use the register to enable the I2C0 directly on your side at first.

Any updated information, please let me know.
Have a great day,
Kerry

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[EugeneHiihtaja]

Hi Kerry !

Direct settings cause BusFault as well.

I just wondering what kind of side effect might have privilege elevation what is executed before hand :

clock_ip_name_t clock = s_i2cClocks[I2C_GetInstance(base)];
_SYSCALLD(/**/CLOCK_EnableClock(clock)/**/);
CLOCK_EnableClock(clock);

Those double call works and privileges returns back for sure becouse it checked in macro :

#define _SYSCALLD(CODE) \
{ \
   BaseType_t xRunningPrivileged = xPortRaisePrivilege(); \
   CODE; \
   vPortResetPrivilege(xRunningPrivileged); \
   if (inSupervisorMode()) \
   { \
     PRINTF("FATAL : user privilege is dropped !\r\n"); \
     panic(); \
   } \
}

and

int inSupervisorMode(void)
{
return !(__get_CONTROL() & 0x1);
}

Can some enabled caches bring this effect ? I have ftfx and L1 caches enabled

Multiple calls works as well, no Bus fault !

_SYSCALLD(/**/CLOCK_EnableClock(clock)/**/);
CLOCK_EnableClock(clock);
CLOCK_EnableClock(clock);
CLOCK_EnableClock(clock);
CLOCK_EnableClock(kCLOCK_I2c0);
SIM->SCGC4 |= (1<<6);

But dummy syscall dosn't help and bus fault is apears 

_SYSCALL(_PRINTF("Dummy syscall !\r\n"));
CLOCK_EnableClock(clock);

and other clocks enabling work here as well  ! No bus fault

clock_ip_name_t clock = s_i2cClocks[I2C_GetInstance(base)];
CLOCK_EnableClock(kCLOCK_PortB); 
CLOCK_EnableClock(kCLOCK_Lptmr1);
_SYSCALLD(/**/CLOCK_EnableClock(clock)/**/);
CLOCK_EnableClock(clock);
CLOCK_EnableClock(clock);
CLOCK_EnableClock(clock);
CLOCK_EnableClock(kCLOCK_I2c0);
SIM->SCGC4 |= (1<<6);

Why I2c0 and 1 is different ?

Regards,

Eugene

[EugeneHiihtaja]

Hello !

2 more observations :

1. Disable clock call is not cause Buf Fault :

..

CLOCK_DisableClock(clock);
_SYSCALLD(/**/CLOCK_EnableClock(clock)/**/);

...

2. If I enable I2C0 clock at main() level  e.g before OS starts

    first EnableClocks works in task context without supervisor privileges.

But after that If I call I2C_MasterDeinit() and Init again -> Bus fault again.

It looks like privileged call give one time permission.

Regards,

Eugene

[kerryzhou]

Hi Eugene,

  Could you please share your small test project with me, which just can reproduce the problem.

  I will test it on my FRDM-K82 board when I have time.

  Please also add the CLOCK_EnableClock(kCLOCK_PortB) which can work OK.

Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------