Supervisor Mode

Hi Thomas

Is this issue resolved? I see somewhat similar sounding posts from you w.r.t to gel files execution getting stuck during PSC initialization and getting fixed by adding kick register unlock.

FYI, the PSC and UART registers accesses do not require ARM to be in supervisor mode.Is this test also being done on the LogicPD SOM board? Can you also share the details on the functions PSC_ModuleClkCtrl().

Regards

Mukul

The issue is not resolved but you are correct that this is linked to my other post. I have noticed that if I go to the GEL view once I am connected to the target, older versions of the GEL files are being linked to despite having updated the paths in the project and in the target configuration. If I simply force the new GEL file to be loaded (which will only be valid until my workspace is reopened as it doesn't seem to want to save), then I still see the issue of the GEL file getting hung up.

If I let the GEL file load fail and stick with the old GEL configuration then the memory map is never updated appropriately and I am unable to update any registers as the memory map must be incorrect. Either way both issues come back to my inability to load the right GEL file and update the memory map. Oddly enough though, I am able to start stepping into my own code which is set up correctly through a vector table we copy in to handle interrupts on the ARM.

The test is being performed on the LogicPD SOM at this point and you should be able to view the PSC function if you simply search for PSC.h and PSC.c in the code base of BIOS or the OMAP code provided by TI. I don't feel it matters for you to look at this particular funtion as much as it matters that any memory write to registers outside of the ARM memory space seem to fail. My assumption here then has to be that the memory map is simply not being written correctly which would point back to my GEL problems that I am unable to permanently resolve.

Alright, after playing around with different SOMs and different workspaces with different GEL files I think I have figured out how to recover my connection. Once I connect and it fails setting up memory but it still allows me to remain connected I run the following:

Target->Reset->CPU Reset (ICE-HW)

All the other Resets do not work but this one allows you to recover your ability to successfully load your GEL upon connection and all of the memory is then set up correctly. I may want to post this on the other post as well in case people run into a similar issue.

Hi Thomas

Thanks for the additional clarifications and updates.

So if I gather all of the issues at hand

1) In your application code (outside the gel file), somehow you see dependency on having ARM in supervisor in order to configure/access registers in the UART and PSC memory maps.

2) You see somewhat similar behavior in your gel files, where the accesses to PSC registers (clock enable functions) seem to hang, and you are able to work around it by writign to kicker registers.

3) The GEL file is not executing correctly/reliably and sometimes not getting updated in your workspace, in your CCSv4 + XDS510USB setup

4)  You think because the desired GEL file does not get executed reliably, the target memory map is not getting set properly, and as  result the your application code does not run reliably. If the GEL file does get execute properly, you don't see any issues with the UART/PSC code.

5) When the gel file execution is hung up, you are able to recover via CPU Reset (ICE-HW)

Let me know if I missed something.

For #1, I will re-iterate again that specifically for accessing UART and PSC registers it should not matter whether ARM is in user or supervisor mode. ARM in supervisor mode is going to be needed for accessing most the SYSCFG registers, and setting up the interrupt stacks , enabling irq/fiq etc.

For #2, the kicker registers should also have not modified/changed the behavior, as the PSC clock enable functions only touch the PSC registers (especially since your code would hang on CC0 initialization itself). Not sure why that is.

For #3, #5 I have requested the CCS and emulation teams to also look at this, as I am not able to reproduce your issue with my CCSv4 + XDS100v2 setup.

Regards

Mukul

Thomas Price said:

The documentation says that when you enter a Software Interrupt that you enter Supervisor Mode. Is there another way for me to enter Supervisor Mode?

Taking a software interrupt to get into supervisor mode is what seems to be most commonly used, as far as I know that is the right way to switch if you are in user mode.

Thomas,

What GEL file are you using for the ARM? Is it something your wrote or did you get it from Logic (OMAPL138_ARM.gel)

thanks

ki

I am using the PDLogic gel file you mention with two changes. One is the KICK register change which is probably not having much of an effect and where it tries to map the ARM interrupt controller memory address I had to change it to 0xFFFE E000 because it had the wrong address in there before.

Mukul-

Sorry I didn't answer sooner but you have correctly summarized it. I have also sent an email to Katie the FAE in Longmont with additional detail. One manifestation of the potential corruption is that the Uart does not send out data correctly. I almost looks like the Idle Polarity is switched. Another manifestation is that the PINMUX settings come up with all sorts of weird default variables. Katie will probably forward you my detail. Hopefully we can figure out what is going on here.

              -Thomas

Thanks for the update.

Two more things to keep in mind, incase we missed in this email traffic, and might or might not apply to your issue

1) Keep in mind that to reliably configure the pinmux registers via ARM in a non-OS type application that you are builiding , please ensure that ARM is in supervisor mode , while accessing the SYSCFG registers

2) For CCS based debug etc, it would be recommended to change the SYSCFG.SUSPSRC register from default (DSP) to ARM as the emulation suspend source. Sometimes not having this done, will trip you on CCS based debug.

Regards

Mukul