Instruction pipeline issue

[kinetis_user]

A pipeline issue  in K10?

I think I am seeing a strange pipeline issues.

I have a code running fine , I’ve added an initialize instruction before a function call , and I’ve got an interrupt because “ the chip tried to fetch a command from a non executable location”

The problem existed no matter which variable I am initializing.

I’ve traced the source of the unhandled interrupt to be not the instruction itself, but its location in memory.

See below “good” and “bad” code

I think it is a pipeline issue, as I was able to get rid of the problem by adding a NOP instruction before the problematic instruction or by moving the code a few bytes in memory

I’ve looked at Freescale and ARM datasheet , and the only thing I could find is that the pipeline is 6 word (32bit) long so it can contain up to 3 32 bit instructions or up to 6 16 bit instructions. I couldn’t find a way to tell the hardware to use a pipeline with only 1 or 2 words instead of 3,

Has anyone seen that problem before and have a better solution? , I don’t like the idea of adding NOPs , because this is just like putting a band aid , I may face that problem again in the future.

See code below

BAD CODE

          Init_Boot:

000015f8:   stmdb sp!,{r4-r10,lr}

000015fc:   sub sp,sp,#40

1642      bool BOOT_OK=TRUE;

000015fe:   movs r1,#1

00001600:   add r0,sp,#0

00001602:   strb r1,[r0,#2]

1644      char Boot_state_machine=0;

00001604:   movs r4,#0

1655      low_address=0x3FFFF; // max address in block 1 of flash memory

00001606:   movw r6,#0xffff

0000160a:   movt r6,#0x3

1656      high_address=0;

0000160e:   movs r7,#0

1657      exit_reason=EXIT_BOOT_FAILED;

00001610:   mov r9,#0x1

// Changing the order of lines 1642-1655 (assembly address 0x15FE – 0x1606) didn’t help , as long as there was an assembly instruction in  memory location –0x1606 , the memfault interrupt was triggered.

// Removing the initialization of a variable before the function called , that caused memory location to shift – and probably have different scenario in the pipeline – no errors existed, see below “Good” code

GOOD

          Init_Boot:

000015ec:   stmdb sp!,{r4-r10,lr}

000015f0:   sub sp,sp,#40

1642      bool BOOT_OK=TRUE;

000015f2:   movs r1,#1

000015f4:   add r0,sp,#0

000015f6:   strb r1,[r0,#2]

1644      char Boot_state_machine=0;

000015f8:   movs r4,#0

1655      low_address=0x3FFFF; // max address in block 1 of flash memory

000015fa:   movw r6,#0xffff

000015fe:   movt r6,#0x3

1656      high_address=0;

00001602:   movs r7,#0

1657      exit_reason=EXIT_BOOT_FAILED;

00001604:   mov r9,#0x1

1677      StrPut(TX_BUFFER,"TEST",4);

00001608:   ldr r3,[pc,#0x34e]

0000160c:   ldr r0,[pc,#0x34e]

00001610:   ldr r1,[pc,#0x34e]

// No new instruction in memory location 0x1606.

Now taking the “bad” code and adding a NOP , made the code to work

BAD with NOP -->GOOD

          Init_Boot:

000015f8:   stmdb sp!,{r4-r10,lr}

000015fc:   sub sp,sp,#40

1642      bool BOOT_OK=TRUE;

000015fe:   movs r1,#1

00001600:   add r0,sp,#0

00001602:   strb r1,[r0,#2]

1644      char Boot_state_machine=0; //

00001604:   movs r4,#0

1654      asm(NOP);

00001606:   nop

1655      low_address=0x3FFFF; // max address in block 1 of flash memory

00001608:   movw r6,#0xffff

0000160c:   movt r6,#0x3

1656      high_address=0;

00001610:   movs r7,#0

1657      exit_reason=EXIT_BOOT_FAILED;

00001612:   mov r9,#0x1

// This time by placing a 16 bit instruction in memory location 0x1606 , instead of a 32 bit instruction as before , solved the problem

[kinetis_user]

And here is an answer I did not expect to get from Freescale tech support

I have submitted the same question to Frescale support by creating SR.

Here is the latest response from Fracases (I have omitted the full name of the tech support person)

I would like to add that I have seen in my past strange pipeline issues (not in Fracases chips), especially with brand new chips , that were later corrected in the next chip revision (or the next compiler version). I am not claiming that this is a pipeline issues , but it is a possibility , whatever code I am writing that causes the start of an assembly opcode to be in a specific memory location causes the problem and by adding a single NOP instruction the problem disappeared. So it does sound an interesting problem. Yes the problem can be because of my code ,but I didn't expect such sort of answer. It is my "C" code , but it is Freescalse compiler , assembler and linker...

====================See below =================================================

Hi xxx

You don't have to provide me your whole project. Just send me the one that can reproduce your problem.

You know, your code is in C language, if this "issue" does exist, many people should have seen it.

Thanks.

BR,

-----Original Message-----

From: Sent: Tuesday, August 02, 2011 8:48 PM

To: Subject: RE: SR# 

Dear xxx,

I assume that just running the "bad" code will not show you anything , as only now did I got that problem so it is probably depends on other things as well. If it was an easy problem to reproduce , I should have seen it before and in more cases.

The part number for the chip I'm using is PK10N512VMD100 0M33Z CTPFP 1039D If I will send you the entire code and project files, will you be able to run it on a K10 system/simulator?

Thank you.

xxx

-----Original Message-----

From: 

Sent: Monday, August 01, 2011 11:15 PM

To: 

Subject: RE: SR# 

Hi xxx.

I have tried your "bad" code, but nothing special found.

Could you please provide me more information regarding of this problem, at least, I can reproduce your problem at my side. I don't think this is because of "pipeline" issue.

Thanks.

BR,

xxx