i.MX28 How to configure for highest performance possible?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX28 How to configure for highest performance possible?

Jump to solution
1,266 Views
stefaankiebooms
Contributor I

One of my customers is using a i.MX28 EVK.

Performance appears abysmal in comparison to slower running ARM9 parts from other vendors.

The documentation and values in the registers indicate the CPU ought to be running at 433 MHZ

performance appears as if the CPU or maybe the AHB memory bus is running only at 24Mhz.

The application (code & data) is running out of OCRAM

Are any documents or recipes that show how to configure the i.MX28 EVK for highest performance possible?

Thanks!

Stefaan

Labels (1)
0 Kudos
1 Solution
742 Views
VladanJovanovic
NXP Employee
NXP Employee

Can you provide a little bit more information?

  • What OS are you running?
  • What tests are performing badly according to you?
  • Your comment suggests you might be running bare-metal code directly out of OCRAM. If it is so, can you share clock initialization sequence you're using?

i.MX28 can run up to 454MHz, but I believe default speed at power-on is 24MHz, which may explain results you're seeing. I suggest checking OBDS can for examples of clock tree setup. Below is code example:

//****************************

// CLOCK set up

//****************************

// Power up PLL0 HW_CLKCTRL_PLL0CTRL0

//setmem /32 0x80040000=0x00020000

    ldr r0,=0x80040000

    ldr r1,=0x00020000

    str r1,[r0]

// Set up fractional dividers for CPU and EMI - HW_CLKCTRL_FRAC0

// EMI - first set DIV_EMI to div-by-2 before programming frac divider

//setmem /32 0x800400F0 = 0x80000002

    ldr r1,=0x80000002

    str r1,[r0,#0xF0]

// CPU: CPUFRAC=19 480*18/29=454.7MHz, EMI: EMIFRAC=22, (480/2)*18/22=196.4MHz

//setmem /32 0x800401B0=0x92921613

    ldr r1,=0x92921613

    str r1,[r0,#0x1B0]

// Clear the bypass bits for CPU and EMI clocks in HW_CLKCTRL_CLKSEQ_CLR

//setmem /32 0x800401D8=0x00040080

    ldr r1,=0x00040080

    str r1,[r0,#0x1D8]

// HCLK = 227MHz,HW_CLKCTRL_HBUS DIV =0x2

//setmem /32 0x80040060=0x00000002

    ldr r1,=0x00000002

    str r1,[r0,#0x60]

View solution in original post

0 Kudos
2 Replies
743 Views
VladanJovanovic
NXP Employee
NXP Employee

Can you provide a little bit more information?

  • What OS are you running?
  • What tests are performing badly according to you?
  • Your comment suggests you might be running bare-metal code directly out of OCRAM. If it is so, can you share clock initialization sequence you're using?

i.MX28 can run up to 454MHz, but I believe default speed at power-on is 24MHz, which may explain results you're seeing. I suggest checking OBDS can for examples of clock tree setup. Below is code example:

//****************************

// CLOCK set up

//****************************

// Power up PLL0 HW_CLKCTRL_PLL0CTRL0

//setmem /32 0x80040000=0x00020000

    ldr r0,=0x80040000

    ldr r1,=0x00020000

    str r1,[r0]

// Set up fractional dividers for CPU and EMI - HW_CLKCTRL_FRAC0

// EMI - first set DIV_EMI to div-by-2 before programming frac divider

//setmem /32 0x800400F0 = 0x80000002

    ldr r1,=0x80000002

    str r1,[r0,#0xF0]

// CPU: CPUFRAC=19 480*18/29=454.7MHz, EMI: EMIFRAC=22, (480/2)*18/22=196.4MHz

//setmem /32 0x800401B0=0x92921613

    ldr r1,=0x92921613

    str r1,[r0,#0x1B0]

// Clear the bypass bits for CPU and EMI clocks in HW_CLKCTRL_CLKSEQ_CLR

//setmem /32 0x800401D8=0x00040080

    ldr r1,=0x00040080

    str r1,[r0,#0x1D8]

// HCLK = 227MHz,HW_CLKCTRL_HBUS DIV =0x2

//setmem /32 0x80040060=0x00000002

    ldr r1,=0x00000002

    str r1,[r0,#0x60]

0 Kudos
742 Views
stefaankiebooms
Contributor I

1)What OS are you running?

We are running Threadx, using IAR tools, but Threadx is not even in the picture until C main is reached. The clocks are configured from a script before the application is downloaded.

2)What tests are performing badly according to you?

We have a basic test application that loops through the scheduler, at the core are two threads sending each other messages, the run count is very low compared to similar ARM9 platforms from other vendors (I port this application all the time, I know what the number should look like)

3)Your comment suggests you might be running bare-metal code directly out of OCRAM. If it is so, can you share clock initialization sequence you're using?

I don't have it here but I will try to get the customer involved here, or obtain the code/script.

Thanks for your suggestions so far!

0 Kudos