NetBurner Community Forum

I have a legacy project built with NNDK 2.6.5 running on a custom board with a Nano and an FAT32 micro SD card. The Nano is able to access the file system just fine.

I compiled a new project with NNDK 2.8.4, and I'm not able to access the same card on the same hardware. f_mountfat returns F_ERR_NOTFORMATTED, even though I know it's FAT32 and mounts fine with the 2.6.5 image. To try to eliminate my project as the source of errors, I compiled the 2.8.4 EFFS-BASIC example project and f_mountfat returns the same error code there as well. Output from the EFFS-BASIC example:

DHCP assigned the IP address of :192.168.0.100
Retrieving external flash usage...

*** Error in f_getfreepace(): F_ERR_NOTFORMATTED

Creating test file: TestFile.txt
*** Error in f_open(TestFile.txt) during task(Main)
F_ERR_INVALIDNAME
Unmounting SD/MMC card

Program complete. Reset to repeat

Does anyone know if there were breaking changes in the NNDK between those versions, or am I doing something wrong? Thanks!

Hm...There really haven't been any notable changes to the SD card system between the two versions that we're aware of. I've run the same test as you here in the office with a nano and a nano carrier board running a clean version of 2.8.4 and the EFFS-BASIC app on a FAT32 formatted micro-SD card. The program seems to be running fine and reading the files as expected.

I copied a copy of my _app.s19 file to this ticket if you want to try it for yourself. From there, I'd do a couple tests. Run the same test with the same parameters I gave you above and if there's still a difference, it's your SD card. If the test works and you put it in your custom hardware and then it doesn't work, it's probably a hardware issue. If it works both ways and you try to compile the same image on your side but aren't successful running in the dev board, send me a copy of your file and we'll try to test it. Then I'd try to compile the same basic example on 2.6.3 and see if that works on either board as well just as a control test.

Let me know what you find out and I'll see if there's anything else we can notice. There is an additional SD card detection check we added in 2.8.5, but that doesn't seem to be relevant here. In 2.8.4 and previous, the off-board check was always returning true regardless of if a card was inserted or not. In 2.8.5 the card detect line gets checked appropriately.

Thanks for the reply. I did as you suggested and ran your _APP.s19 on a Nano and SD card using the NB carrier board, and everything worked fine. I compared the schematics between our custom board and the Nano carrier board, and it looks like we're using pin 15 for the card detect/data 3 line (the Nano carrier is using pin 37 I think?). I couldn't find anything in our application code that used the Pins class to do this, but did find a change to the 2.6.5 Nano's mmc_mcf.c that changed three lines starting at 803 from
to along with a note indicating a change from SPI1_CS1 on PF0 to SPI1_PCS0 on PF2. It also changes lines 899 and 927: I was thinking this was changing pin 15 to use SP1 chip select 0, so I tried recompiling the 2.8.4 EFFS-BASIC example using Pins[15].function(PIN_15_DSPI1_PCS0), but I still got the same error code. Maybe there's other pin changes I haven't found yet, or my understanding of the above code changes are wrong (or both).

Since you only change the card detect pins, my guess is your problem is there...
The two function in mmc_mcf.cpp are:


bool InternalCard_CD() //Pin C14 port G1
{
sim1.gpio.par_simp0h&=0xFC;
sim1.gpio.pddr_g &= ~0x02;

return ((sim1.gpio.ppdsdr_g & 0x02)==0);
}


/*-------------------------------------------------------------------
Get Card Detect state
RETURN: 0 - card is removed
1 - card present
-------------------------------------------------------------------*/
int get_cd(int CurrentDrive )
{
if( CurrentDrive == ONBOARD_DRIVE_INDEX )
{
return InternalCard_CD();
}
else
{
return true;
}
}


Are you using the wrong index where it thinks its the internal CD?

It's possible... get_cd() is being called with no parameters and I haven't found the default argument or overloaded function so I don't know what's being passed in for the CurrentDrive param. That said, get_cd() doesn't return 0 with a card present.

It's the subsequent call to f_mountfat() which fails, I think because it calls mmc_initfunc, which in turn calls MMC_BaseInit. Someone had made the changes to MMC_BaseInit in our 2.6.5 repository - the stuff in my last post - which isn't there in 2.8.4. That code has changed between NNDK versions, and I'm not yet sure how to integrate our old changes in the new version.

I am trying to get the internal SD card to work on the SB800EX hardware. I receive the same error code F_ERROR_NOTFORMATTED. The demo EFFS-BASIC source file FileSystemUtils.cpp states that if you have an internal drive MULTI_MMC should be defined. This is not defined because MOD5441X is not defined. If I define MOD5441X in this file and change variable flashDriveNum to equal ONBOARD_DRIVE_NUM I can get the card detection switch to function. In the source file mmc_mcf.cpp it seems there are more on board card defines commented out. Is there a schematic for the SB800EX internal card slot? I think I need to check if the IO and pin modes are correct at the SPI driver level. Is there a demo that is out of the box functional to use the internal SD card on the SB800EX hardware? I also tried to format the card using the FormatExtFlash function since it formatted the same drive number the was prior initialized. Any ideas of the software changes needed to get an operational SD card on this box?

Hello John,

The onboard flash sockets for both the Nano and SB800EX use the SDHC interface instead of native SPI. It is significantly faster, using 4 data lines instead of 1. The example and updated drivers for the SB800EX did not make it into the 2.8.5 release. If you can open a support ticket we will send you the necessary code.

To clarify, the off-module flash socket on the Nano dev board is still SPI.

The MOD5441x core module's on-board flash socket is SPI. The SDHC driver did not exist at the time we designed the modules.
The flash socket on the MOD-DEV-70 dev board uses SPI
The signals exist on the MOD5551x headers to use either SDHC or SPI for any of the boards you design to plug the module into

All other core modules are SPI at this time.