Important note for MOD5441X and probabbly nano54415 users...

[pbreed]

We have had some serious interrupt latency problems with the MOD54415
We have not seen the problem on the NANO and this is probably due to not having the flex bus turned on.

The short story adding ...

sim1.ccm.misccr|=0x0700;

To the hardwareinit function in nburn\mod5441x\system\bsp.c file

(or you can #include <sim.h> and add that line ANYWHERE it will get executed)

Seems to fix the issue...


The long story...
We have a lot of code in our system that looks like:

if ( pDHCPTick )
{
pDHCPTick();
}

This compiles to something like:
moveal pDHCPTick,%a0
testl %a0
beqw skip
jsr @a0

skip:

This processor has an aggressive pipeline and it seems that the system
attempts to load the @a0 in case the branch is not taken
This causes an access to address 0 that is not mapped, and the bus then freezes until the bus timeout interval has passed.

The one line above shortens the bus timeout interval to as short as possible.
We are also looking at other ways to resolve this and have an active discussion going with freescale about this.

[dciliske]

The following code has been added to the bsp.c file for the MOD5441X platform to resolve the issue, we are currently running confirmation tests to see if any unexpected issues occur over time.

Code: Select all

     // The following code is to prevent latency spikes when the processor 
    // performs a speculative load from a null function pointer or other loads 
    // to unmapped memory
    sim1.ccm.misccr|=0x0700; //Turn bus timeout down.
    // Setup NULL catching FlexBus chip select
    sim2.cs[2].csar = 0x00000000; // Set base address to 0x0000_xxxx
    sim2.cs[2].cscr = 0x00000100; // Enable internal transfer acknowledge
    sim2.cs[2].csmr = 0x00000001; // Set the valid bit for this chipselect

Note: chip select 2 is not available offboard (or even off-chip), so it can not conflict with any signals used by users. However, this change does make the address range 0x0000_0000 - 0x0000_FFFF unusable by endusers (although this adress range should not be used in general).

[dciliske]

We have been running multiple test units now for close to 72 hours and none experience any of the previous latency issues or other effects. As such, we are placing this fix in the mainline production code and declaring it resolved.