[AM3359 & FatFS] Did someone successfully write data on microsd memory card?

Eugenio,

I assume you talk about IA-SDK 1.0.0.7? As far as I  know we have not tried any example where we write to SDcard. We only use SDcard for booting (read) so far.

The support for MMC is coming from the team that develops Starterware and we have not done any additional tests I assume.

So we need to move that question to the Starterware forum. Unfortunately I am not able to do that. But may the person managing this forum.

Regards.

Frank, thank you for your reply.

Yes, I'm using starterware 1.0.0.7. ChaN's FatFS provided with starterware is version 0.04b, that has a known bug with FAT32 drives:

http://forum.rfeda.net/archiver/tid-515259.html

---

For users of Elm FatFs v0.04b, I found a nasty bug 

When you call fs_mkdir on a FAT32 system, and the newly created directory start at a cluster >65535, only the lower 16 bits of the cluster address will be taken into account.  As a result, FatFs will store invalid cluster address, and write to the wrong cluster, overwriting data and/or corrupting the file system.



This bug is new as of v0.04b.  Not present in v0.04a.



The bug is in file ff.c, line 1473 (part of fs_mkdir function), there is a conditional '_FAT32'.



Code:Bug! FatFs 0.04b, ff.c, line 1473



#if _FAT32

        ST_WORD(&fw[   DIR_FstClusHI], dclust >> 16);

        if (fs->fs_type == FS_FAT32 && pclust == fs->dirbase) pclust = 0;

        ST_WORD(&fw[32 DIR_FstClusHI], pclust >> 16);

#endif

        ST_WORD(&fw[   DIR_FstClusLO], dclust);

        ST_WORD(&fw[32 DIR_FstClusLO], pclust);


'_FAT32' is not defined anywhere in FatFs.  '_FAT32' is used in Tiny-FatFs version, so this could simply be a copy/paste leftover...

Fix:

Simply remove the conditional #if _FAT32 / #endif

---

Unfortunately this is not enough. So I've tried the newer version of FatFS available from ChaN's site, with no success.

The folder creation works fine, but opening a file for writing doesn't work as described in my previous post.

Hope hear you soon :-) 

Ok, one small step ahead (but no solution so far).

I've found that:

1. HS_MMCSD library checks some IRQ status registers;
2. the issue occurs exactly after 4096 bytes sent to MMCSD module: this sounds to me as some kind of buffer overrun. I'm writing with f_write() function one byte at a time, but no actual card write operation is performed. After 4096 iteration a buffer somewhere get filled and everything stop working.

So, I've carefully read the documentation, and I've found this:

Everything is correct in my application, but I did not enabled master interrupts nor configured AINTC controller (I do not use interrupts in my custom bootoloader, no need for them).

So, I've added these basic initialization function calls (cut&paste from uartecho demo, that uses interrupts), changing fomr UART to MMCSD0:

IntMasterIRQEnable();
IntAINTCInit();
/* Setting the priority for the system interrupt in AINTC. */
IntPrioritySet(SYS_INT_MMCSD0INT, 0, AINTC_HOSTINT_ROUTE_IRQ);
/* Enabling the system interrupt in AINTC. */
IntSystemEnable(SYS_INT_MMCSD0INT);

And then:

HSMMCSDInit();

that does these setup operations:

void HSMMCSDInit(void) {

HWREG(SOC_PRCM_REGS + CM_PER_MMC0_CLKCTRL) |= 0x2; // MMC0
HSMMCSDPinMuxSetup();xferPend = 0;

cmdCompFlag = 0;
cmdTimeout = 0;
errFlag = 0;
sdBlkSize = MMCSD_BLK_SIZE;
hsmmcsd_dataLen = 0;
hsmmcsd_buffer = NULL;

g_sPState = 0;
g_sCState = 0;

g_cCwdBuf[0] = '/';
g_cCwdBuf[1] = '\0';

/* Basic controller initializations */
HSMMCSDControllerSetup();

/* Initialize the MMCSD controller */

MMCSDCtrlInit(&ctrlInfo);

MMCSDIntEnable(&ctrlInfo);

HSMMCSDFsMount(0, &sdCard);

}

But, with all this stuff on, I get a "IRQ exception default handler" with program counter stuck in 0x20094 deadloop as soon as the software tries to access mmcsd. Even for reading!.

At last, I figured out that this exception could come from interrupt vector not being filled up properly with ISR service routines address.

Problem is: I cant' see where actual MMCSD interrupt funtions are placed into interrupt vector.

In basic UART demo application this is the interrupt registration function call:

IntRegister(SYS_INT_MMCSD0INT, UARTIsr);

and the itnerrupt function is UARTIsr.

In MMCSD library, where is the ISR funtion to be registered? Documentation does not even mention that...

eugenio said:

But, with all this stuff on, I get a "IRQ exception default handler" with program counter stuck in 0x20094 deadloop as soon as the software tries to access mmcsd. Even for reading!.

- Some info on the IRQ exception are given in the ARM documentation:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344k/CHDFIJEI.html

As you mentioned the deadloop could be linked to an Interrupt handler not being filled. The IntDefaultHandler() defined in AM335X_StarterWare_02_00_xx_xx\system_config\armv7a\am335x\interrupts.c does use an infinite loop as default handler.

- You might be able to look with the JTAG debugger where the vector table is placed and what IRQ handler are initialized. The interrupt verctor table is setup by the some code present in AM335X_StarterWare_02_00_xx_xx\system_config\armv7a\am335x\startup.c.
It might be that the CPU gets stucks step 5 or step 6 described in Fig 6.2 at page 193 of AM335x TRM - SPRUH73H.

I am not completely sure but it might be possible to test that CPU jumps to the int handler just by manually setting the according bit in the INTC_ISR_SETn register. If it is the case you could just write the bit corresponding to the SD card interrupt (see section 6.3 tab 6.1 of TRM) to see to which int handler the CPU jumps too.

- Also have you looked at AM335X_StarterWare_02_00_00_05\examples\beaglebone\demo\demoSdRw.c ?
Teh MMCSD interrupt seems to be used in this code.

Hope it helps.

Anthony

I've found that bootloader application provided with am335x_sysbios_ind_sdk_1.0.0.7 does not initialize any interrupt vector table... 

No code is called from AM335X_StarterWare_02_00_xx_xx\system_config\armv7a\am335x\startup.c. (NOTE:  I'm using am335x_sysbios_ind_sdk_1.0.0.X, not  AM335X_StarterWare_02_00_xx_xx, but I think this makes no difference).

Application entry point is "Entry" in bl_init.asm, and no init procedure sets ISR functions addresses at 0x4030_FC00, where ISR vector table is supposed to be in.

Looking with memory browser at 0x4030FC00 I read all zeroes.

UartEcho demo has different bl_init.asm,  that calls start_boot in startup.c, and thus interrupt vector table is filled up with valid addresses for basic cpu interrupts.

All this stuff does not explain yet:

• starterware MMCSD library provided with am335x_sysbios_ind_sdk_1.0.0.7 needs interrupts?
• what MMCSD library functions needs to be registered as interrupt functions?

eugenio said:

(NOTE:  I'm using am335x_sysbios_ind_sdk_1.0.0.X, not  AM335X_StarterWare_02_00_xx_xx, but I think this makes no difference).

I can not confirm if it make a difference but I think it might.  The am335x_sysbios_ind_sdk_1.0.0.X does use a subset of the Starterware and I don't think that validation has been done on the part of the starterware that are not used in the SDK.
To use the full functionnality of the Starterware I would strongly advise to use the AM335X_StarterWare_02_00_xx_xx as only this package has been fully validated and tested.

I understand that your focus is the Industrial SDK however as of today only a limited set of the starterware functionnality has been used and validated on ICE/IDK using Ind SDK.
You should use the Starterware to start with functionnality not present in the Industrial SDK. I understand that using this code might not be straigth forward as it requires to use the beaglebone/EVM or starterkit that you might not have.

eugenio said:

All this stuff does not explain yet:

• starterware MMCSD library provided with am335x_sysbios_ind_sdk_1.0.0.7 needs interrupts?
• what MMCSD library functions needs to be registered as interrupt functions?

Have you look already at the AM335X_StarterWare_02_00_00_05\examples\beaglebone\demo\demoSdRw.c ? I believe that MMCSD interrupt is used as part of this code.

Eugenio,

examples provided with IA-SDK (folder sdk/examples) are Sys/Bios projects and thus assume interrupt table is initialized by Sys/Bios startup code. As Starterware examples assume no OS, they can't be easily mixed with other code provided in IA-SDK.

Regards,

Hi Frank!

I'm aware of this: I spent hours to get DMTimer StarterWare library to work with SysBios...

But: I need microsd to be written in a Sys/Bios application (ethercat application based upon ecat_appl in ICE demoboard's SDK). So, I need to merge StarterWare stuff with Sys/Bios.

The problem is that StarterWare MicroSD demo itself doesn't work, and no documentation is provided. Other software from complete SDK - as suggested - uses DMA, that makes even more difficult merging it in SysBios software...

So, still in troubles... 
My company could pay for this kind of support, but no one seems to be interested in this "support" business here in Italy...

Apology for late response.

In release 02.00.00.07 hs_mmcsd example is implemented for read operation only.

Please refer hs_mmcsd example of latest release 02.00.01.01 which supports fatfs write operation (f_write). Refer Cmd_cat().

Regards,

Ramesh D

Hi Eugenio, hopefully you're still getting emails from this discussion.  I just want to know if you did end up successfully getting the MMCSD port to work with SysBios. 

I am having a similar issue right now integrating a working FATFS project from a starterware example into our own SYSBIOS project.  I'm getting hangs during the initializing process and also get "FR__NOT_READY" on a f_open after mounting the card.  I think it has something to do with the SD commands not being sent out right, but not sure how to check that.