PROCESSOR-SDK-AM437X: Combine QSPI and FATFS Console Project

Hi Inno,

I cannot tell exactly what could be missed. Maybe you can compare the xdc configuration files of the two projects and see if there is anything else from project  “QSPI_BasicExample_idkAM437x_armExampleProject” that needs to be added to project "FATFS_Console_idkAM437x_armExampleProject".

Regards,

Jianzhong

Hello Jianzhong,

Thank you very much. I was able to make some progress due to your advice. As you said, there was indeed something missing in the XDC config file. Now I am able to to get access to the QSPI flash but the FAT file access functions crash with the same kind of error. Let me explain...

At the end of the XDC configuration file for the "FATFS_Console_idkAM437x_armExampleProject" you will see the following lines:

I identified that inside the XDC configuration file of the "QSPI_BasicExample_idkAM437x_armExampleProject", there are additional lines, which I simply copied to the FAT example project (see red rectangle in the following picture). I have to admit that I don't know the meaning of those instructions.

Nevertheless, from now on I can access own written functions that read meaningful data out of the QSPI flash via the help of the QSPI nor flash driver from TI (I highlight them with a greed rectangle) but the software crashes now when I call file access functions such as "FSShellAppUtilsFrmtPath" (see red rectangle in the following picture). And the crash is almost identical with what I initially reported. 

So copying the instructions from the QSPI to the FAT XDC config file repairs the QSPI flash access but breaks the FAT function calls. 

My questions are:

1) What is the meaning of the lines, which are placed at the bottom of the XDC configuration files (the function call Mmu.setFirstLevelDescMeta() )?
2) How can I make it happen, that within the same project I can access the NOR flash driver functions and also in parallel the file access driver functions?

Thanks,

Inno

Hi Inno,

Mmu.setFirstLevelDescMeta() is from the memory management unit. Please refer to <BIOS installation folder>/docs/cdoc/ti/sysbios/family/arm/a8/Mmu.html for details.

The crash problem you had was most likely caused by conflict of MMU configurations from the two example projects. You may also want to look at this thread which has some good explanation of MMU usage: https://e2e.ti.com/support/processors/f/791/t/908657. 

Hello Jianzhong,

I will read the E2E post and the HTML documentation inside the SDK carefully. I found the following statement inside the E2E post that you mentioned above:

"The MMU will generate exceptions without these translation table entries when when CPU attempts R/W access to addresses in these pages."

This is most likely what happens to me in my initial post.

In the meanwhile it seems that I also found the cause of my second crash. This is not connected to the MMU configuration. I guess I identified a bug inside the "FATFS_Console_idkAM437x_armExampleProject" project. I basically copied certain code from the "FSShellAppUtilsCmdCat" to my own function, but I believe that even inside the "FSShellAppUtilsCmdCat" is a bug. 

Please look at the below "FSShellAppUtilsFrmtPath" function call:

You see above that the function "FSShellAppUtilsFrmtPath" is being called with the argument "argv[1U]" in any case. "argv[1U]" is a pointer, which points to the 2nd argument of the console command. If I type in e.g. the console command "cat readme.txt", then "argv[1U]" points to the 'r' of "readme.txt".

But what if I call the "cat" command without any further argument? In this case "argv[1U]" may not be initialized and may point anywhere! So I managed to let the software crash even when calling the "cat" command out of the UART console.

What I believe is missing inside the function "FSShellAppUtilsCmdCat" is code like this:

if(argc <= 1)
{
   FATFS_log("Too little arguments, enter filename when calling CAT !!!!\n");
   return CSL_ESYS_FAIL;
}

What do you think, can this be a bug?

Another question, the program of the example projects runs on the DDR memory starting at the base address of EMIF at 0x80000000. So why do we need to add, inside the XDC configuration file, a table entry to the ARM MMU translation table for the peripheral registers, which the code accesses, but not for the DDR memory? I wonder why the following lines, taken from the "Mmu.html" file, is not part of every example project configuration file:  

// Set the descriptor for each entry in the address range
for (var i=0x80000000; i < 0x90000000; i = i + 0x00100000) {
    // Each 'SECTION' descriptor entry spans a 1MB address range
    Mmu.setFirstLevelDescMeta(i, i, attrs);
}

I would also expect that the ARM core creates an exception if he does not identify a "translation table hit" when accessing the DDR.

Thanks,

Inno 

inno said:

So why do we need to add, inside the XDC configuration file, a table entry to the ARM MMU translation table for the peripheral registers, which the code accesses, but not for the DDR memory?

E.g. in bios_6_73_01_01/packages/ti/sysbios/family/arm/a8/Mmu.xs there is the function module$static$init which has a loop which iterates through Program.cpu.memoryMap adding MMU table entries.

Where the ti.sysbios.family.arm.a8.Mmu SYS/BIOS module is also used for the Cortex-A9 AM37x devices.

Thank you Chester. I found the following inside the map file:

So the MMU translation table is most likely located on the DDR memory. So how can the SYS/BIOS configuration add the DDR memory sections to the MMU table, which resides on the DDR? Isn't this a conflict? At the beginning I would assume that the DDR is not accessible except the ARM core operates in a state where he does not involve any memory translation operations.

Jianzhong, what about the issue that I had with calling "FSShellAppUtilsFrmtPath" when no argument has being used in the console when calling a command. Can this be a bug?

inno said:

At the beginning I would assume that the DDR is not accessible except the ARM core operates in a state where he does not involve any memory translation operations.

bios_6_75_02_00/packages/ti/sysbios/family/arm/a8/Mmu.c contains the functions which setup the MMU.

Thank you Chester, this explains everything.

Jianzhong, can you please check about my above question regarding the example project? Does it make sense calling "FSShellAppUtilsFrmtPath" when no further argument has being entered by the user in the console when calling a command. Can this be a bug? Afterwards I can close this E2E post.