About MPC5744 Instruction Fetch Error

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

About MPC5744 Instruction Fetch Error

1,310 Views
liujinhang
Contributor III

Dear all

    We meet a trouble when using DMA,We trigger the DMA to transfer data at a frequency of 160khz continuously, 32bytes per minor loop, During this time, if the flash programming operation occurs synchronously, an Instruction Fetch Error will be set,then code run away.

following is the description of the error register and DMA process diagram.

pastedImage_8.png

Detailed information is on page 414 of MPC5744 UM.

pastedImage_2.png

Through the debugger Trace32 we can see the instructions in the following section is destroyed by someting we do not know,When the program executes  “g_u32_FlashProgramStart”,a function of EEPROM Emulation Software Driver

pastedImage_25.png

We wonder that  if it is beyond the maximum capacity of the internal bus when DMA transferation and the flash programming operation occurs synchronously?

or we use the DMA in a wrong way?

How can we do to avoid such an error?

Thanks!

0 Kudos
Reply
5 Replies

884 Views
aero72
Contributor III

Hi,

Looks like your flash program failed for that page. I'd be very cautious about using any other processor function during a flash program operation.

Have you made certain that you're not trying to 'Read-While-Write' from the same flash partition....i.e. make certain that the program that has the flashing algorithms is not in the same flash partition as the memory you are programming.

Personally, I would avoid using other processor features whilst doing erase and program operations - but if you must do this, you should use the callback function features of the NXP algorithms. These features allow you to schedule time-critical algorithms during program operations at places in those algorithms where crucial flash operations are not taking place.

DMA transfer however is not something that you can schedule...you can request a transfer start at a known time. When that transfer completes is up to the DMA and you have no control over it.

One other thought. Is the memory you are accessing/transferring with DMA potentially being erased or programmed by the flash algorithm?

Good luck.

0 Kudos
Reply

884 Views
liujinhang
Contributor III

Smith,

thanks for your response.

we already knew that the  'Read-While-Write' will effect program working in same flash partition, so we checked our code and we confirmed that the flash program operation only happened at the EEPROM-Simulition area. in this case,it is impossible to happen  'Read-While-Write'  in same flash partition. 

because our problem be found after we enable a DMA channel, so we think if the DMA using bus will effect flash program operation?

 

i want to know, is there any possible of the flash program operation can be effect by DMA in some cases?

0 Kudos
Reply

884 Views
aero72
Contributor III

I'm still thinking the problem will be in what the program is doing, rather than a bus capacity issue.

A couple more things to think about then...

a) Is there a possibility the RAM being used by the flash programming algorithm (i.e. its storage for variables) is being overwritten by DMA operation?

and,

b) if you're using the flash block at 0x1000000 as simulated E2 (as it appears from your screenshot), keep in mind this is a 256k block....and it will take a *long* time to erase and program - data sheet says up to 4s. Also keep in mind these blocks are designed only for a limited number of program cycles - datasheet says < 1000 - and as such, it isn't best used for E2 simulation.

Have you allowed for the potentially long and very variable time that this erase and program cycle will take - the time taken will change greatly with temperature if your unit is exposed to cold and hot temperatures.

The smaller flash blocks in other partitions will erase/program more quickly, and are guaranteed 250k write cycles.

Hope that helps.

0 Kudos
Reply

884 Views
liujinhang
Contributor III

Hi smith,

can DMA effect BUS working?

0 Kudos
Reply

884 Views
liujinhang
Contributor III

hi smith,

thanks for your response.

a)we do have used RAM to be the target of the DMA, but the problem is why the address of the program operation chenged to be APP area. we already knew the DMA target RAM is only global variables area, not stack area that can effect program running.

another important information is that all flash program operation is in function of “g_u32_FlashProgramStart”, and all calling “g_u32_FlashProgramStart” functions is using local variable to be target address parameter.

b)we used 0x1000000 as APP area in flash. the simulated E2 adress is 0x00800000 to 0x0080FFFF but not 0x1000000.

so our biggest problem is why we used wrong address to be .g_u32_FlashProgramStart target address parameter, especially using local variables to be  target address parameter?

0 Kudos
Reply