exception when trying to write to certain memory locations.

The problem in this post looks identical (http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/t/182544.aspx).  However the L3 clock is setup in the gel file and I cannot find anywhere in the technical reference manual that details that the GPMC clock is gated from the L3 clock to need enableing?

Sean

Hi Sean,

Your question is best answered by the experts in the device forum. I will move it there.

Thanks

ki

Is anybody at TI able to offer me any support with this?

Thanks

Sean

Sean, most likely you do not have the proper internal clock enabled to access the GPMC.  Your code may possibly be undoing what the GEL is enabling.

The GPMC uses a single clock CORE_L3_ICLK.  There is not a separate control for this GPMC clock.  Try enabling CORE_L3_ICLK by enabling either CM_ICLKEN1_CORE (0x48004a10) bit 1 (EN_SDRC) or bit 4 (EN_HSOTGUSB). 

Regards,

James

I am affraid I am unable to check this currently as the EVM board is now doing nothing but as soon as I can get this problem solved http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/t/268716.aspx

I will look back at this.

Regards

Sean

Good afternoon,

Now I have everything working again I am back to this.  The EN_SDRC bit is high (enabled) and so is the EN_HSOTGUSB bit (I can see this in the registers view in ccs).

The the very first command in my code is

unsigned int test = (*(unsigned int *)(0x6D000010));

Which causes the exception.  This address is a sdram contol register it also wont let me read or modify these as well as the fash ones.

Can you think of any other clock gates or something missing the the gel file maybe that would stop me being able to access these registers?

Many thnkas

Sean

Sean, do you have MMU enabled in your code?

Regards,

James

Hi James,

Section 8 of the technical reference manual (about the MMU) only covers the Camera and IVA2.2 MMU units and says the MPU MMU is covered in the MPU subsystem chapter.  But that chapter doesnt really mention it at all and does not show any registes where it could be anabled.  I also would think that if the MMU was disabled I would not be able to access the registers to set up the UART3 or GPIO6 which I am doing sucessfully.

It is only the registers to do with the memory controller I am having this issue with.  Can you think of any other possablilities or give me more direction on how to check the MMU is enabled if you belive this could be the issue still?

Many thanks

Sean

Good morning,

I am sure that I am missing something simple but I still have not been able to figure this out could somebody please help me?

Thank

Sean

Hey Sean,

I'm just a newbie user, but I think if you look at your map file it will probably tell you that you haven't set up that segment of memory. If that's the case, check this page http://rtsc.eclipse.org/docs-tip/Memory_Management and it will tell you how to use the platform wizard to set up that memory. That page also has a lot of good info on the inards of the platform.xdc files and linker cmd files. Hope this helps.

Dave

Good morning Dave,

I dont belive this can be the problem because the memory map setup with the platform only specifies data/code memory space not control registers such as these and the ones to set up things like the UART and SPI (both of which I can access).

The portion of the memory map set up by the gel files is specified as

/* !! FOLLOWING MEM SPACE TO BE CONFIGURED PROPERLY !!*/    

GEL_MapAddStr(0x68000000, 0, 0x98000000, "R|W|AS4"    , 0);  /* TO BE CONFIGURED */

Although it says it is not configured properly the only differance between how this is configured and the UART3 registers are configured that I can access is the AS4 is AS1 for the UART3.  Can anybody tell me the differance?

Most other parts are AS4 and there isnt any obvious logic to the differance between AS1, AS2, AS3 and AS4 to me.

Kind regards

Sean

Good afternoon,

I am still no further on this issue.  I guess that no body on here is able to help me as I am getting no responses, so what do you do when the TI emplyees on the TI support form cannot help?  Are you able to put me in touch with someone that may be able to help?

Many thanks

Sean

Good afternoon,

I am still stuck on this, I find it very hard to belive that this is not something simple i am missing, as surley being able to set up and write to the flash/RAM are important in nearly all applications.

Kind rgeards

Sean

Good afternoon,

Still have no solution to this... any one able to give me any support on this forum?

Regards

Sean

Sean,

I was asked to try to help with some tips to get additional insights on the problem (I understand about CCS but not much about the device itself nor its GEL initialization routines).

- Before you load/run any code, can you open a Memory Browser view on CCS and make sure you are able to point to the address that is failing (namely 0x6D000010)? This will rule out any problems with the tool itself or the initial device configurations performed by the GEL scripts.

- Then, after you load your code and run to main(), can you check the bottom status bar to see if the processor is in Supervisor mode (it should read SPV) and the MMU is off (it should read MMU off)? That usually helps verify if the processor is in the same condition as when it is coming straight from reset (where everything is accessible). Depending on the compiler and runtime support library you are using, it is possible it switches to User mode before reaching main(), thus rendering most (if not all) low-level memory accesses impossible and throwing an exception.

- Before you run the code, can you go back to your Memory Browser view and try to view the register you are using? This will help see if your code somehow made this area inaccessible.

- I don't think this is applicable to your case, but if your code is in external memory and any configuration changes are done to the memory interface controller (EMIF), this will probably (or definitely) render your program unusable (I've done that...)

Please check if these tips help you pinpoint when and where the inaccessibility is taking place in your system.

Hope this helps,

Rafael

Hello Rafael,

Thank you very much for the reply, MMU was On and when I turn this off in the scripts I can read and write to these locations.  I cant see any where in the Gel files where this is turned on and as it is a feature of the Cortex itself I guess there is no option to turn it on in CCS so either the u-boot or x-loader must be turning it on.  Does this sound correct or is there somewhere in CCS that it can be turned on/off?

It is also not in SPV mode but in SYS (System (privileged) mode) is this another feature of the Cortex and what does it mean?

The reason to access these registers is to program/erase the flash with configuration information and booting code.

Again thank you for your reply, I new it would be something simple I was missing.

Kind regards

sean

Actually when I have been running the program in debug and restart it from main again the MMU gets turned back on therefor it seems it must be either what ever happens before main, CCS or the Gel files turning it on.

Do you know which of these it will be and how to stop them?

Many thanks

Sean

Hello,

A little bit more information for you.  If I disable the MMU from the scripts menu in ccs (using the gel files) the code runs until BIOS_start() then after entering BIOS_start() it does nothing (ie doesn't enter any of my interrupt code or the idle loop).  If I re enable the MMU before entering BIOS_start() he program works as normal.  This would suggest that the sys/bios sets up the MMU then checks for it/requires it for some reason.

So it seems just disabling it in my code could cause undesired results and crashes.  Is there a way to stop the sys/bios blocking these addresses and letting it continue to use it for what it needs?

Many thanks

Sean

Hi,

Could some body pleas confirm for me whether it is the SYS/BIOS that sets up the MMU and why it requires it?

Kind regards

Sean