Concerto mtoc_ipcdrivers example hangs the m3 core on ipc read

Larry,

can you step into the code and see at what access it hits the hard fault. It will throw some light on the issue. Also check the parameters that you pass to the functions in watch window, the addresses etc etc.

Best Regards

Santosh

  Thank you, Santosh.  I will double-check the function arguments.  

  I have discovered some additional symptoms.  It always makes it through the return to main, from the IPCMtoCDataRead() function.  The values are written properly to the variables on the c28.  However, there must be some corruption occuring that I haven't discovered yet, because the m3 hard fault will occur on any code I put after it, even a simple counter loop.

  What's really strange is if I single-step, slowly, through the code that follows the return from IPCMtoCDataRead(), it usually makes it through.  But if I try a "run to line," it immediately faults.  I have already tried lowering the clock speeds.  It didn't seem to help.

  One other symptom, the IPC_MTOCIPCFLG_IPC17 is either not being set or is being overwritten, because it is not set when it gets to the line that tests it.

Larry

Larry,

can you check if the test application is remapping the NVIC table and check if any stale interrupt is occuring? Also check if address you are asking C28x to read via IPC, if that address is RAM-INIT'd and if it is EALLOW protected?

on the MTOCIPCFLG17 issue - are you saying if you set it from M3 core adn read back to check if the flag is set, you don;t see it set? or you are saying that the flag is not cleared by C28?

Best Regards
Santosh

Santosh,

  To be clear, I am using the "mtoc_ipcdrivers" example straight "out of the box" (C:\ti\controlSUITE\device_support\f28m35x\V140), so I'm assuming that it is initializing memory and interrupts correctly.  It is a standard F28M35H52C1 control card.

  My .cmd files are "\MWare\cmd\F28M35x_generic_wshared_M3_FLASH.cmd" for the m3.  The .cmd files for the c28 are "F28M35x_common\cmd\F28M35x_generic_wshared_C28_FLASH.cmd"  and  "\F28M35x_headers\cmd\F28M35x_Headers_nonBIOS.cmd"  I have not modified them.  Should these work for the "mtoc_ipcdrivers" example?

  I am sorry, I mis-stated the issue with MTOCIPCFLG17 flag.  I meant to say that it was not being cleared (I had a very long day!).

  I agree that it sounds like a stale interrupt, because the hard fault is occuring at different points in the code.  Also, because it occurs as soon as I let the code run.  But, I have unchecked the "Disable Interrupts" options in the debugger, so they should be firing as I step through the code. 

  The variables that are read/written are just globals on both cores.  I suspect this is an addressing or memory mapping disagreement between the two cores. But for me, this is a new MCU, an unfamiliar IDE and debugger and my first time with dual core, which might be a litte too much for my feeble mind to figure out!  So it would be nice to start with a known good setup, then anything that goes wrong is due to my mistake.  So, I'd really like to know, for sure, that I'm starting with the correct .cmd files.

  Thanks again for your help.

Regards,

Larry

http://e2e.ti.com/cfs-file.ashx/__key/communityserver-discussions-components-files/171/8666.F28M35x_5F00_generic_5F00_wshared_5F00_M3_5F00_RAM.cmdLarry,

I just tried the example by running from RAM, it works fine. Can you try below

1.> comment out the below line of code from your M3 main() function. You could keep this commented out when you are loading in flash and running from flash. But remember to uncomment this when you want to run the test in stand alone. Because when you have debugger connected, and load C28 application the control subsystem is already out of boot. 

// Send boot command to allow the C28 application to begin execution

// IPCMtoCBootControlSystem(CBROM_MTOC_BOOTMODE_BOOT_FROM_FLASH);

2.> When I tired to link the RAM configuration of the example, the linker threw some errors. It is because the F28M35x_generic_wshared_M3_RAM.cmd file in v140 of controlSuite has some errors. I raised a flag for this to be corrected. The *_Flash one is fine. So use the attached one to link code in RAM build configuration.

Build and load code on M3 and C28, run C28 and then RUN M3...it should work.

Now, this example as such is not modified or updated to run from flash. I spoke ot the team and they are aware of it and will be fixing it in next REV. Mean while if you want to run from flash, you can modify this example easily after you get it working from RAM. Below are the steps.

A.> As long as you are running from flash with debugger connected, you can keep the function said above in comment #1 commented. Once you re ready to test this stand alone uncomment the function and reflash M3.

B> The NVIC table in the example is pointed to 0x20005000, but when you build the example for flash thats not where the default NVIC table is at. Have a look at theIntRegister function in interrupt.c (driver lib), you will have to call this function registering hte IPC interrupt handler, this will fix the NVIC table for you. It is not enough if we just enable the IPC interrupt we will have to rgister the handler.

C.> Take a look at M3 flash example in C:\ti\controlSUITE\device_support\f28m35x\v140\F28M35x_examples_Dual\flash, the M3 code calls a flash Init function from its main. The example main has to do the same thing with correct defines.

with above modifications you will get it running from flash too. Hope it helps.

Best Regards
Santosh