PSP driver demo runs but aborts

Hi Cobsonchael,

I assume you are using the BIOSPSP version 03.00.01.00. Have you tried running the default binaries(executables) that come with the BIOSPSP package?. If so, do you get the same abort message?. Are you using all the tools as mentioned in the BIOS PSP Userguide?. Have you done any modifications in the build setup or in the sample application?.

cobsonchael said:

BIOS.heapSize and Memory.defaultHeapInstance have both been set. BIOS.heapSize ignored. Using Memory.defaultHeapInstance. mmcsdSample.cfg /mmcsdsample ti.sysbios.BIOS XDCTools Configuration Marker

This warning message can be avoided by removing the following line from the application mmcsdSample.cfg file -

BIOS.heapSize = 0x2000;

Best Regards,

Raghavendra

i have not tried the default binaries that came with the package. i made a project, followed the user guide and video of how to set up a project, built it and ran.  i did not modify any of the project files. this is why i am coming here before trying to debug it because this isn't my project, it's TI's. i didn't write any of the files that are included in it so any aborts, warnings, errors, failures i am going to ask about before i debug.

since i did not modify any of the files why is that warning there at all? shouldn't we have been provided with a project with no warnings or errors?

It looks like someone is calling Memory_free() (which calls HeapMem_free()) with a bad address.   HeapMem has alignment constraints and HeapMem_free() sees an address with bad alignment and call Assert().

Which version of SYS/BIOS are you using?   If you are using SYS/BIOS 6.33.00 or later, you can add the following to your .cfg file to build a "custom" library.  This custom library is built from the sources on your disk.

var BIOS = xdc.useModule('ti.sysbios.BIOS');
BIOS.libType = BIOS.LibType_Custom;

You can then add a line like the following to HeapMem which will catch the error.  If you halt CCS, you should get a stack backtrace showing the call stack of the code that called Memory_free() with a bad address.

    if ((UArg)addr & HeapMem_reqAlignMask) != 0)) {
        for (;;) {
        }
    }

-Karl-

so i removed that line of code and tried again. it still aborted.

so then i tried the prebuilt binary.  that ran all the way through without an issue.

so it is not my gel file but likely some project build setting that i have wrong.

would you like to look at any of my files to help me figure this out?

Yes sure, Please share your project files..

Best Regards,

Raghavendra

here is my project. let me know what i am doing wrong please!

Hi Raghavendra --

One of big differences between COFF and ELF is that ELF initializes all uninitialized variables to '0', while COFF leaves them undefined.   I'd look for some variables that do not have explicit '=0', that have this assumption.

-Karl-

Thanks for your input Karl, Let me check this..

Best Regards,

Raghavendra

well that seemed to do it. i knew it was some small build setting thing that was messing everything up. thanks for the help!

ok, so since changing this to ELF allowed it to work does that mean that I HAVE TO USE ELF if i plan on using FATfs?  does that mean every third party library we have requires a recompile in ELF?

Hi Karl,

In the mmcsd_fatfs application, we use the drive id: 1

I did some debugging, and observed that the “FatFs[1]” in the FAT Filesystem is not initialized to zero. i.e, the global structure - “FATFS *FatFs[_VOLUMES]”

When we try to do a f_mount(…) is when we get the abort. Following is the code snippet of f_mount(..) in ff.c file of BIOS FATfs

/*-----------------------------------------------------------------------*/

/* Mount/Unmount a Logical Drive                                     */

/*-----------------------------------------------------------------------*/

FRESULT f_mount (

        BYTE vol,               /* Logical drive number to be mounted/unmounted */

        FATFS *fs               /* Pointer to new file system object (NULL for unmount)*/

)

{

        FATFS *rfs;

          if (vol >= _VOLUMES)                    /* Check if the drive number is valid */

                return FR_INVALID_DRIVE;

        rfs = FatFs[vol];                               /* Get current fs object */

…

..

.

Only “FatFs[0]” will be initialized to zero. The rest of the volumes are not initialized.

I tried to manually iniatialize “FatFs[1]” to zero, including its “win[_MAX_SS]” object in CCS. After doing so, the application registered the device and completed successfully without any abort/failure.

Best Regards,

Raghavendra

so do i need all new libraries or ...?

Most everything we do is moving to ELF.   I will file a bug report to ask that this be fixed in COFF.

Here's a workaround.  I've attached a project example. 

7128.coff-zero-fill.zip

[1]   Add a user .cmd file to your project that includes the .far placement as well as defining variables for the base/size for the .far section.   CCS supports multiple .cmd files.

SECTIONS {
    .far: RUN_START(_far_start), RUN_SIZE(_far_size), load > DDR
}

[2]  Add C function to your app that uses these variables to fill the .far section with '0'.

Void zerofillfar()
{
    extern far char *far_start;
    extern far size_t far_size;

    memset(&far_start, 0, (size_t)&far_size);
}

[3]  Update your .cfg file to call this 'zerofillfar()' function very early in the boot process.  SYS/BIOS has a Startup module that you can hook into to call your function very early in the boot cycle.   This function is called before any variables are initialized.

var Startup = xdc.useModule('xdc.runtime.Startup');
Startup.resetFxn = "&zerofillfar";

[4]   Make another change to your .cfg file to exclude the .far placement from the generated .cmd file.

Program.sectionsExclude = ".far";

See attached example for more.   I built and ran this and verified correct fill of .far with 0.   I did not test with FATFS though.

Regards,
-Karl-

bug id is SDOCM00094671

that did work with FATFS. thanks for the help.

i am new to following bug fixes. where do i go to watch the status of the bug fix?

cobsonchael said:

i am new to following bug fixes. where do i go to watch the status of the bug fix?

https://cqweb.ext.ti.com/cqweb/main?command=GenerateMainFrame&service=CQ&schema=SDO-Web&contextid=SDOWP&username=readonly&password=readonly

The above link will provide you the ability to monitor the specific bug id indicated by Karl, SDOCM00094671.

Hi Raghavendra,

I have the same problem as mentioned and u mentioned that initializing FatFs[1] to zero works.

Can you teach me how to do it.

I am a novice in this.

The fatfs is in a separate folder and is only link to the main program by include files.

So i supposed i cannot make any changes to the fatfs-> ff.c file.

So how do i initialize FatFs[1] to zero

Thanks.

Regards,

Amy Chua

[1]  Look at this post ror a workaround:

Posted by Karl Wechsler

Hi Karl,

I download 6.34.01 and uses ELF but my code still hangs at f_mkfs.

I did change the instance to 1 because i am using MMCSD port 1.

Would this be the reason why the program doesnt work?

Thanks