About MPC5744 Instruction Fetch Error

[liujinhang]

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.

Detailed information is on page 414 of MPC5744 UM.

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

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!

[aero72]

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.

[liujinhang]

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?

[aero72]

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.

[liujinhang]

Hi smith,

can DMA effect BUS working?

[liujinhang]

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?