Bus- Hard- MemManage Faults and Screen messing up using eGUI on TWR-K60 and TWR-LCD

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

Bus- Hard- MemManage Faults and Screen messing up using eGUI on TWR-K60 and TWR-LCD

1,046 Views
dominate606
Contributor I

I have a problem with the eGUI on a TWR-K60 Kit with the TWR-LCD module.

 

I made a project using the D4D eGUI to display some screens, derived it from the official demo in the eGUI software package.

I added USB Host support, which I took from the Codewarrior 10.1 Examples Kit. I took the hidmouse example and added keyboard support.

I added terminal support and use the P&E Terminal for some "printf debugging".

For debugging I implemented the busfault/usagefault/memfault and hardfault ISRs.

 

I have now a strange problem, which I've been trying to solve now for some time:

When I change screens (using the function D4D_Activate_Screen(..)) the screen starts to mess up after a few screen changes, displaying no title bar, placing the scroll bar somewhere on the screen, and the button I use to display a menu of screens stops working.

 

Sometimes I get a BusFault or MemManageFault with weird values on the BFAR or on the stacked PC, when the MCU tries to execute code in the heap mem. The USB stack and the D4D functions make heavy use of global data structures with pointers to functions, which I've seen changing after initialization, which should not happen.

 

I have the feeling that the compiler places different global variables in the same memory area which leads to altering of function pointers and finally to the mentioned faults.

 

The question is now, what I can do against it; how can I make the compiler (or the mem manager) use correct memory allocation? Or is it just something wrong or missing in my project?

 

Thanks!

Dominik

0 Kudos
5 Replies

729 Views
dominate606
Contributor I

Update.

 

To get out of the dead end I have come to I removed the D4D library from the project (excluded the files from build and removed the function calls from main). After some addtions to my terminal, to temporarily use the terminal instead of the lcd as user interface, the hid task for the usb keyboard stops working. I find that during execution some function pointers in the usb host structures get overwritten to point into nirvana, resluting in the attachment process to fail with some error code.

 

Maybe someone has a suggestion what could be the problem? Seems to me to be a basic problem with the memory allocation ...

 

Thanks, Dominik

0 Kudos

729 Views
LuisCasado
NXP Employee
NXP Employee
Hello, Is your project code bigger than 256k of flash? Best Regards, Luis
0 Kudos

729 Views
dominate606
Contributor I
When downloading it says code size is about 80k, far away from 256.
0 Kudos

729 Views
LuisCasado
NXP Employee
NXP Employee

Hello,

 

Silicon 1.0 had similar issue when crossing Flash boundaries. But it should happend with more than 256k of flash. In any case try to add this code:

 

  FMC_PFB0CR&=~(FMC_PFB0CR_B0DCE_MASK | FMC_PFB0CR_B0ICE_MASK | FMC_PFB0CR_B0DPE_MASK | FMC_PFB0CR_B0IPE_MASK);

  FMC_PFB1CR&=~(FMC_PFB1CR_B1DCE_MASK | FMC_PFB1CR_B1ICE_MASK | FMC_PFB1CR_B1DPE_MASK | FMC_PFB1CR_B1IPE_MASK);

 

This will disable the flash cache. The issue has been fixed in the new production silicon.

 

Best Regards,

 

Luis

0 Kudos

729 Views
dominate606
Contributor I

Luis,

thanks for your support. I added the code my sysinit. No change, still "MemFault". After some screen changes, the MemFault ISR is activated. After the ISR, execution returns to 0xDFFD8CF6, which is right in the middle of nowhere (according to the mem-file in "Flexbus for external memory", filled with 0xBA).

 

Dominik

 

 

0 Kudos