RTOS/AM3352: Reading USB DevCtl crashes system

Since I haven't heard back from anyone about why simply reading from the USB Dev Ctl register would crash the processor, is there any other way for a USB device to detect if there is a host physically connected supplying VBUS voltage?

No difference using uint_8 type.  The problem is not when the data gets stored, it's when the USB Device Control register (or Interrupt Status register) gets read.  The modified source and compiled code is shown below.

802 uint8_t Usb_DevCtl = /* Crash -> */HWREG(USB0_BASE + USB_O_DEVCTL);
807d4564: E59FCFA4 ldr r12, [pc, #0xfa4]
807d4568: E59CC000 ldr r12, [r12] <--- Causes exception
807d4570: E6EF107C uxtb r1, r12

R12=0x47401460 (uSB Device Control address) at time of crash.

Kevin Jennings

Hi Kevin

We are not aware of any read restriction with the DEVCTL register. It should be readable. Are you running the USB as host mode or device mode?

Can you manually read the address 0x47401460 from the Memory Browser in Code Composure Studio?

Best regards

Thanh

To your earlier post:  Nothing from 0x47401400, USB0 Core is readable (shows up as ???????? in the memory browser).  Nothing from 0x47400000 USB SS is readable either.

To your later post about USB is not powered up, USB clock is not turned on, or MMU has not been setup for this USB region:  USB must be powered on and the clock running.  The two programs that I'm using are working functional code that have been in production for several years.  The only thing that I have added is to get status using HWREG(USB0_BASE + USB_O_DEVCTL), mask off bit 3 and pass that up to through our firmware stack to report on whether or not there is something connected to USB.  The one program uses the USB CDC driver, the other does not.  Since both programs are completely functional without the modification to add the single "HWREG(USB0_BASE + USB_O_DEVCTL)" statement, the problem can't be like USB not powered or clocks not running.

I do have to correct one statement from my previous post.  USB0 Core registers starting at 0x47401400 ARE readable in Code Composer's memory browser window when I'm running the program that does not use the USB CDC driver.

Since the data abort exception is happening right on the assembler instruction that performs the read from memory location 0x47401460 (aka USB0_BASE + USB_O_DEVCTL) this implies that the system is thinking that the address is invalid to be read from.  Since this only happens when using the USB CDC driver it suggests one of the two scenarios:

- The non-CDC driver program does something to enable memory access to USB registers that the USB CDC driver program does not enable

- The USB CDC driver does something to disable memory access to USB registers

In either scenario, the fix would be to make sure that memory access to USB registers are enabled in the USB CDC program.  So now the question would be what is the mechanism for enabling/disabling access to USB registers?  If the USB CDC driver is intentionally disabling access, then a further question would be 'Why?'

Kevin Jennings

Hi,

Issue is that you don't use any of our exist PRSDK code and things are different:

In your CCS project map file, there should be a symbol called:

ti.sysbios.family.arm.a8.mmuTableSection

               0x80200000     0x4000

*(ti.sysbios.family.arm.a8.mmuTableSection)

ti.sysbios.family.arm.a8.mmuTableSection

               0x80200000     0x4000 C:\ti\pdk_am335x_1_0_13\packages\MyExampleProjects\USB_DevMsc_evmAM335x_armExampleProject\Debug\configPkg\package\cfg\usb_arm_am335x_pa8fg.oa8fg

               0x80200000                ti_sysbios_family_arm_a8_Mmu_Module_State_0_tableBuf__A

Look at this address from CCS memory window (the beginning portion may be zero, just scroll down):

You see there are entries like 0X40201e0e, 40301e0e,...... 0x44e00e12, ..... 0x47400e12. ....

This is the MMU table, the 0x47400e12 is for the address 0x4740_0000 with 1MB size, you may need to check ARM doc to decode what 0xe12 means. But at least you need have such entry in your MMU. Do you see this in working case and failure case?

Regards, Eric

Digging deeper.  The mmu tables are initialized in a generated function called ti_sysbios_family_arm_a8_Mmu_initTableBuf__I which is in the file configPkg/package/cfg/app_pea8fnv.c, see below for the contents.  The text '80001E' (from the MMU entry for 0x80101e0e) also shows up in another generated files configPkg/package/cfg/app_pea8fnv.cfg.xml.  The line in this .xml file is miles long but looks like this:

<feature name="tableBuf" type="object"><vector id='ti.sysbios.family.arm.a8.Mmu/tableBuf'  length='4096'><elem>undefined</elem><elem>undefined</elem>....<elem>0x80001e0e</elem>...

From there is a bit murky as to what application source(s) is(are) used to generate the .c and .xml files, but I believe that XDC generates both based on at least on the application specific file called app.cfg.  Comparing the app.cfg files for the two programs does not shed any light but here are the differences:

CDC:  execontextInstance0.memoryMap["DDR3"].len = 10485760;

no CDC: execontextInstance0.memoryMap["DDR3"].len = 7340032;

Both programs define two semaphores, the app.cfg entries for both are identical.  The app.cfg for the CDC program has nine additional semaphores defined that are only in the non-CDC app.cfg.  An example is the following:

var semaphore3Params = new Semaphore.Params();
semaphore3Params.instance.name = "semFrontIQFComplete";
Program.global.semFrontIQFComplete = Semaphore.create(null, semaphore3Params);

The .project file for the two programs are nearly identical, the only difference being in the <name>...</name> tag.

There is also a am335x.cmd file which is identical for the two programs, shown below as well.  Reading 'How to Develop a Project With TI SYS/BIOS' at http://www.ti.com/lit/an/sprabw1/sprabw1.pdf, the example there seems to have a few more entries where I only have a .init section.

To summarize...

- It is unclear what source file(s) XDC is using to generate the MMU table since nothing in app.cfg looks like it would do that directly.

- While the app.cfg file is different for the two programs, there does not seem to have any difference that would cause USB registers to not be available.

- Is app.cfg supposed to have something in it that is missing from both?  If so, why does the non-CDC program work and is able to read USB registers even though the MMU table is virtually the same as the CDC program?

Not clear where to look next.

Kevin Jennings

===== Start of configPkg/package/cfg/app_pea8fnv.c contents =====

From configPkg/package/cfg/app_pea8fnv.c for the CDC driver program

Void ti_sysbios_family_arm_a8_Mmu_initTableBuf__I(UInt32 *mmuTableBuf)
{
mmuTableBuf[1026] = 0x40201e0e;
mmuTableBuf[1027] = 0x40301e0e;
mmuTableBuf[1152] = 0x48000e12;
mmuTableBuf[1154] = 0x48200e12;
mmuTableBuf[2048] = 0x80001e0e;
mmuTableBuf[2049] = 0x80101e0e;
mmuTableBuf[2050] = 0x80201e0e;
mmuTableBuf[2051] = 0x80301e0e;
mmuTableBuf[2052] = 0x80401e0e;
mmuTableBuf[2053] = 0x80501e0e;
mmuTableBuf[2054] = 0x80601e0e;
mmuTableBuf[2055] = 0x80701e0e;
mmuTableBuf[2056] = 0x80801e0e;
mmuTableBuf[2057] = 0x80901e0e;
}

From configPkg/package/cfg/app_pea8fnv.c for the non-CDC driver program

Void ti_sysbios_family_arm_a8_Mmu_initTableBuf__I(UInt32 *mmuTableBuf)
{
mmuTableBuf[1026] = 0x40201e0e;
mmuTableBuf[1027] = 0x40301e0e;
mmuTableBuf[1152] = 0x48000e12;
mmuTableBuf[1154] = 0x48200e12;
mmuTableBuf[2048] = 0x80001e0e;
mmuTableBuf[2049] = 0x80101e0e;
mmuTableBuf[2050] = 0x80201e0e;
mmuTableBuf[2051] = 0x80301e0e;
mmuTableBuf[2052] = 0x80401e0e;
mmuTableBuf[2053] = 0x80501e0e;
mmuTableBuf[2054] = 0x80601e0e;
}

===== End of configPkg/package/cfg/app_pea8fnv.c contents =====

===== Start of app.cfg contents for program using CDC driver =====

var Defaults = xdc.useModule('xdc.runtime.Defaults');
var Diags = xdc.useModule('xdc.runtime.Diags');
var Error = xdc.useModule('xdc.runtime.Error');
var Log = xdc.useModule('xdc.runtime.Log');
var LoggerBuf = xdc.useModule('xdc.runtime.LoggerBuf');
var Main = xdc.useModule('xdc.runtime.Main');
var Memory = xdc.useModule('xdc.runtime.Memory');
var SysMin = xdc.useModule('xdc.runtime.SysMin');
var System = xdc.useModule('xdc.runtime.System');
var Text = xdc.useModule('xdc.runtime.Text');

var BIOS = xdc.useModule('ti.sysbios.BIOS');
var Clock = xdc.useModule('ti.sysbios.knl.Clock');
var Swi = xdc.useModule('ti.sysbios.knl.Swi');
var Task = xdc.useModule('ti.sysbios.knl.Task');
var Semaphore = xdc.useModule('ti.sysbios.knl.Semaphore');
var Hwi = xdc.useModule('ti.sysbios.hal.Hwi');
var Mailbox = xdc.useModule('ti.sysbios.knl.Mailbox');
var Timestamp = xdc.useModule('xdc.runtime.Timestamp');
var TimestampProvider = xdc.useModule('ti.sysbios.family.arm.a8.TimestampProvider');

/*
* Program.argSize sets the size of the .args section.
* The examples don't use command line args so argSize is set to 0.
*/
Program.argSize = 0x0;

/*
* Uncomment this line to globally disable Asserts.
* All modules inherit the default from the 'Defaults' module. You
* can override these defaults on a per-module basis using Module.common$.
* Disabling Asserts will save code space and improve runtime performance.
Defaults.common$.diags_ASSERT = Diags.ALWAYS_OFF;
*/

/*
* Uncomment this line to keep module names from being loaded on the target.
* The module name strings are placed in the .const section. Setting this
* parameter to false will save space in the .const section. Error and
* Assert messages will contain an "unknown module" prefix instead
* of the actual module name.
Defaults.common$.namedModule = false;
*/

/*
* Minimize exit handler array in System. The System module includes
* an array of functions that are registered with System_atexit() to be
* called by System_exit().
*/
System.maxAtexitHandlers = 4;

/*
* Uncomment this line to disable the Error print function.
* We lose error information when this is disabled since the errors are
* not printed. Disabling the raiseHook will save some code space if
* your app is not using System_printf() since the Error_print() function
* calls System_printf().
Error.raiseHook = null;
*/

/* set errHook (defined in main.c) as the error
* hook function. Strings begining with '&'
* can be assigned to function pointers to
* reference unspecified external functions
*/
Error.raiseHook = "&errHook";

/*
* Uncomment this line to keep Error, Assert, and Log strings from being
* loaded on the target. These strings are placed in the .const section.
* Setting this parameter to false will save space in the .const section.
* Error, Assert and Log message will print raw ids and args instead of
* a formatted message.
Text.isLoaded = false;
*/

/*
* Uncomment this line to disable the output of characters by SysMin
* when the program exits. SysMin writes characters to a circular buffer.
* This buffer can be viewed using the SysMin Output view in ROV.
SysMin.flushAtExit = false;
*/

/*
* The BIOS module will create the default heap for the system.
* Specify the size of this default heap.
*/
BIOS.heapSize = 3145728;

/* System stack size (used by ISRs and Swis) */
Program.stack = 65536;

/* Circular buffer size for System_printf() */
SysMin.bufSize = 0x200;

/*
* Create and install logger for the whole system
*/
var loggerBufParams = new LoggerBuf.Params();
loggerBufParams.numEntries = 16;
var logger0 = LoggerBuf.create(loggerBufParams);
Defaults.common$.logger = logger0;
Main.common$.diags_INFO = Diags.ALWAYS_ON;

System.SupportProxy = SysMin;
Clock.tickPeriod = 500;
Clock.timerId = 0;
Task.defaultStackSize = 65536;
Hwi.dispatcherAutoNestingSupport = false;
var execontextInstance0 = xdc.lookup('xdc.platform.ExeContext.Instance#0');
execontextInstance0.memoryMap["DDR3"].len = 10485760;
var semaphore0Params = new Semaphore.Params();
semaphore0Params.instance.name = "semInitComplete";
Program.global.semInitComplete = Semaphore.create(null, semaphore0Params);
var semaphore1Params = new Semaphore.Params();
semaphore1Params.instance.name = "semUSBTransferComplete";
Program.global.semUSBTransferComplete = Semaphore.create(null, semaphore1Params);
var semaphore2Params = new Semaphore.Params();
semaphore2Params.instance.name = "semShutdownComplete";
Program.global.semShutdownComplete = Semaphore.create(null, semaphore2Params);
BIOS.cpuFreq.lo = 600000000;
Memory.defaultHeapSize = 3145728;
Program.sectMap["ocmc"] = new Program.SectionSpec();
Program.sectMap["ocmc"].loadSegment = "OCMC_SRAM";
var semaphore3Params = new Semaphore.Params();
semaphore3Params.instance.name = "semFrontIQFComplete";
Program.global.semFrontIQFComplete = Semaphore.create(null, semaphore3Params);
var semaphore4Params = new Semaphore.Params();
semaphore4Params.instance.name = "semRearIQFComplete";
Program.global.semRearIQFComplete = Semaphore.create(null, semaphore4Params);
var semaphore5Params = new Semaphore.Params();
semaphore5Params.instance.name = "semFrontScaleComplete";
Program.global.semFrontScaleComplete = Semaphore.create(null, semaphore5Params);
var semaphore6Params = new Semaphore.Params();
semaphore6Params.instance.name = "semRearScaleComplete";
Program.global.semRearScaleComplete = Semaphore.create(null, semaphore6Params);
var semaphore7Params = new Semaphore.Params();
semaphore7Params.instance.name = "semJPEGProcessorAvailable";
semaphore7Params.mode = Semaphore.Mode_BINARY;
Program.global.semJPEGProcessorAvailable = Semaphore.create(1, semaphore7Params);
var semaphore8Params = new Semaphore.Params();
semaphore8Params.instance.name = "semOCRComplete";
Program.global.semOCRComplete = Semaphore.create(null, semaphore8Params);
var semaphore9Params = new Semaphore.Params();
semaphore9Params.instance.name = "semScaleReturn";
semaphore9Params.mode = Semaphore.Mode_BINARY;
Program.global.semScaleReturn = Semaphore.create(null, semaphore9Params);
var semaphore10Params = new Semaphore.Params();
semaphore10Params.instance.name = "semScanComplete";
Program.global.semScanComplete = Semaphore.create(null, semaphore10Params);
var semaphore11Params = new Semaphore.Params();
semaphore11Params.instance.name = "semImageMemoryAvailable";
semaphore11Params.mode = Semaphore.Mode_BINARY;
Program.global.semImageMemoryAvailable = Semaphore.create(1, semaphore11Params);

===== End of app.cfg contents for program using CDC driver =====

===== Start of am335x.cmd contents used by both programs =====

SECTIONS
{
.init: { boot*(.text)} > 0x80000000 /* make sure we can boot! */
}

===== End of am335x.cmd contents used by both programs =====

lding said:

This is the MMU table, the 0x47400e12 is for the address 0x4740_0000 with 1MB size, you may need to check ARM doc to decode what 0xe12 means. But at least you need have such entry in your MMU. Do you see this in working case and failure case?

E.g. using CCS 9.0.1 to debug the USB_DevMsc_evmAM335x_armExampleProject, with the Cortex-A8 halted, there is the Mmu view of the RTOS Object View (ROV):

There are also the Page Table Visibility DSS API's which can be called from the CCS Scripting Console. E.g. to show there is a one-to-one mapping between the physical and virtual addresses for 0x47401400 which is for the USB0 Core:

js:> ptvReverseLookup 0x47401400
Physical Address = 0x0000000047401400 --> Virtual Address = 0x0000000047401400 


js:> ptvLookupAddress 0x47401400
Virtual Address = 0x0000000047401400 --> Physical Address = 0x0000000047401400 
 = > 
    TTBR0 Base Address = 0x80200000 
    Min VA = 0x0 
    Max VA = 0xffffffff 
     = > 
        Type = L1 Section 
        Index = 0x474 
        Min VA = 0x47400000 
        Min PA = 0x47400000 
        Region Size = 0x100000 
        S = 0x0 
        AP[1:0] = 0x3 
        nG = 0x0 
        AP[2] = 0x0 
        NS = 0x0 
        TEX[2:0] = 0x0 
        XN = 0x1 
        Domain[3:0] = 0x0 

Kevin Jennings said:

It would appear that there must be a call to something in the non-CDC USB device driver that changes whether the MMU blocks 0x47400000 or not but it does so in a way that doesn't affect what appears to be a static MMU table.

Mmu.enableMMU = true;

// Force peripheral section to be NON cacheable strongly-ordered memory
var peripheralAttrs = {
    type : Mmu.FirstLevelDesc_SECTION, // SECTION descriptor
    tex: 0,
    bufferable : false,                // bufferable
    cacheable  : false,                // cacheable
    shareable  : false,                // shareable
    noexecute  : true,                 // not executable
};

// Define the base address of the 1 Meg page
// the peripheral resides in.
var peripheralBaseAddr = 0x44e00400;

// Configure the corresponding MMU page descriptor accordingly
Mmu.setFirstLevelDescMeta(peripheralBaseAddr,
                          peripheralBaseAddr,
                          peripheralAttrs);

                          
// Define the base address of the 1 Meg page
// the peripheral resides in.
var peripheralBaseAddr = 0x481a6000;	// UART3 and other

// Configure the corresponding MMU page descriptor accordingly
Mmu.setFirstLevelDescMeta(peripheralBaseAddr,
                          peripheralBaseAddr,
                          peripheralAttrs);                          

var peripheralBaseAddr = 0x47400000;	// USBSS

// Configure the corresponding MMU page descriptor accordingly
Mmu.setFirstLevelDescMeta(peripheralBaseAddr,
                          peripheralBaseAddr,
                          peripheralAttrs);                          

Can you try adding such a MMU mapping to the .cfg file for your project?

Chester,

When I add the entire section of app.cfg code you posted, the build fails. The offending line in question is "Mmu.enableMMU = true;"

(C:/SourceSafe/SmartSourceElite/Pro2_0TestProject/SmartSourceElitePro2_0/app.cfg#105)
"./package/cfg/app_pea8fnv.cfg", line 195
gmake.exe: *** [package/cfg/app_pea8fnv.xdl] Error 1
js: "C:/ti/xdctools_3_50_04_43_core/packages/xdc/tools/Cmdr.xs", line 52: Error: xdc.tools.configuro: configuration failed due to earlier errors (status = 2); 'linker.cmd' deleted.
gmake[1]: *** [build-1655140127-inproc] Error 1
gmake[1]: Leaving directory 'C:/SourceSafe/SmartSourceElite/Pro2_0TestProject/SmartSourceElitePro2_0/Release'
gmake: *** No rule to make target 'build-1655140127', needed by 'configPkg/compiler.opt'. Stop.

Looking at the structure of app.cfg, it would appear that I would first have to include some form of 'xdc.useModule' command first in order to then be able to use the variable that gets returned. For example, my app.cfg sets a variable 'Memory' like this:
var Memory = xdc.useModule('xdc.runtime.Memory');
Then use 'Memory' like this:
Memory.defaultHeapSize = 3145728;
Looking at the SYS/BIOS documentation, there doesn't appear to be any other XDC module which would return anything similar to your 'Mmu' so it is unclear what further can be done along this front. PDK and SYS/BIOS are too different.

Kevin Jennings

Kevin Jennings said:

Looking at the structure of app.cfg, it would appear that I would first have to include some form of 'xdc.useModule' command first in order to then be able to use the variable that gets returned.

var Mmu = xdc.useModule('ti.sysbios.family.arm.a8.Mmu');

Kevin Jennings said:

The code that is reading from 0x47471460 appears to be in a different task than the one that the USB driver is in. As part of bringing up the USB driver in both programs, a call is made to USB0ModuleClkConfig() in file usb.cpp. When using the non-CDC driver, this call is happening before the first call to the procedure that reads from 0x47401460 but in the CDC driver the call to USB0ModuleClkConfig() happens after the procedure tries to read from 0x47401460. It is upon return from USB0ModuleClkConfig() that the USB registers like 0x47401460 become accessible and readable.

The AM335x peripherals are not readable if their clock is not enabled, so your change to call USB0ModuleClkConfig() before attempting to read from 0x47401460 is correct.

I.e. doesn't appear to be a problem with the MMU setup.