Messages

1

NXP^TM M522XX, KINETIS and i.MX RT / Re: "Intentional Crash" hit in SD simulator?

« on: January 10, 2014, 04:25:30 PM »

Hi Mark,

Examining it some more yesterday, the 'Q' was hex 0x51, which is the CMD17 as the code suggests. The full message was 0x51 0x0 0x0 0x76 0xee 0x0, which is what the call to fnCreateCommand should create.

An interesting thing, however, is that the state the code was in when it processed the 0x51 byte is not something I can deduce. Whatever it was, the 0x51 caused it to go into the SD_CARD_INIT state. You will notice that if it was in INIT state, and it received 0x51, it would have set the state to SD_CARD_ARGUMENTS, so it wouldn't be in the SD_CARD_INIT state for the first 0 byte.

I have saved a backup copy of my SD_CARD.bin, in case you want it. I've erased the bin file and am just going to proceed with a fresh file. If it happens again, I will repost. This is the first time I have seen it or my colleague has seen it. So I'm not sure if it will happen again.

Thanks

-Steve

2

NXP^TM M522XX, KINETIS and i.MX RT / "Intentional Crash" hit in SD simulator?

« on: January 09, 2014, 10:53:20 PM »

I just was simulating my project, and hit this code in fnSimSD_write:

    case SD_CARD_INIT:
        if ((ucTxByte == 0x40) || (ucTxByte == 0x42) || (ucTxByte == 0x43) || (ucTxByte == 0x46) || (ucTxByte == 0x47) || (ucTxByte == 0x48) || (ucTxByte == 0x50) || (ucTxByte == 0x77) || (ucTxByte == 0x69) || (ucTxByte == 0x7a) || (ucTxByte == 0x58) || (ucTxByte == 0x51) || (ucTxByte == 0x49)) { // all expected commands
            ucCommand = ucTxByte;
            iArguments = 0;
            iSD_Card_State = SD_CARD_ARGUMENTS;
            break;
        }
        else if (ucTxByte != 0xff) {                                     // accept idle line, which is used when poll for busy
            *(unsigned char *)0 = 0; // <==== here
        }
        break;


This code died on the line that attempts to write 0 into the NULL address. ucTxByte is 0. It seems to be the second byte in a message from the function fnSendSD_command, with this code:

            for ( ; iCommandState < 6; iCommandState++) {                // command content is always 6 bytes in length
                WRITE_SPI_CMD(ucCommand[iCommandState]);                 // send the command and arguments
                WAIT_TRANSMISSON_END();                                  // wait until transmission complete
                READ_SPI_DATA();                                         // read to clear the flag
            }                                                            // fall through intentional after sending the command

So the call stack indicates we are on the WRITE_SPI_CMD line, and the iCommandState is 1 (ucCommand[0] is 'Q')

More in the call stack:

 case _READING_MEMORY:
        {
            unsigned char ucResult;
            while ((iActionResult = fnSendSD_command(fnCreateCommand(READ_SINGLE_BLOCK_CMD17, ulSector), &ucResult, 0)) == CARD_BUSY_WAIT) {}
            if (iActionResult < 0) {
                SET_SD_CS_HIGH();
                iMemoryOperation &= ~_READING_MEMORY;                    // read operation has completed
                return iActionResult;
            }

In this case, ulSector is 30446.

One thing I should note is that I updated my utFat code but did not delete the simuated SDcard.bin file. Is that the problem?

-Steve

3

utFAT / Re: Mountable version of SD_CARD.bin

« on: September 06, 2012, 06:54:17 PM »

I was thinking of simply using linux dd to copy the bits from a physical SD card to a file, then using that file as the simulated SD card.  Then, when I wanted to examine the contents on a PC, use linux dd to copy them back to the physical card (easy to do this with VMWare   Optionally, I could mount the file directly on Mac or Linux (there has to be a way to do this in Windows, but I'm not sure).

The simulator does not have to be aware of the filesystem layout of the file as far as I know, it just has to be able to seek within the file, right?

Yes, to use a physical SD card *directly*, we would need a way to access it as a file.  I wonder if using CreateFile using the low-level device file name would allow this?  I would guess not unless the SD card driver processes read and write system calls.

On Linux, this would be easy, just open /dev/sdx

-Steve

4

utFAT / Re: Mountable version of SD_CARD.bin

« on: September 06, 2012, 06:09:22 PM »

Further,

It would be fine if I had to take an actual SD card and copy the binary image of it to a file in order for this to work.  In other words, I don't care if the simulator creates the image, I just want to be able to use a mountable image with it.

-Steve

5

utFAT / Re: Mountable version of SD_CARD.bin

« on: September 06, 2012, 05:26:00 PM »

OK, thanks.

I actually would not mind having a fully allocated SD card "image" on my PC, I certainly have 1GB to spare.  I actually am using a Windows VMWare image on a MAC, and I'm pretty sure my mac could mount a full filesystem as a file.

Is it difficult to do this?

-Steve

6

utFAT / Mountable version of SD_CARD.bin

« on: August 31, 2012, 08:25:16 PM »

Hi,

I am just getting back into developing using uTasker, and I was hoping there was a way to mount the simulated SD_CARD.bin on my PC so I can examine the contents and ensure they are valid.

Alternatively, is there a way for the simulator to use a physical SD card inserted into the PC?

Thanks

-Steve

7

utFAT / Re: Detecting the presence of an SD card

« on: October 08, 2010, 01:13:25 PM »

This is good news.  Is there a place where you provide access to your code in development, or do I need to wait for the next release?

-Steve

8

µTasker general / improving efficiency of uTasker kernel

« on: October 07, 2010, 10:02:15 PM »

I have spent some time now getting to know uTasker, and I think I may have seen some room for improvement on the scheduler/driver.

First, all operations on tasks use a linear search through the task table to find the appropriate task.  By sorting the tasks, you can use a binary search that should reduce the runtime of searches.

But even without this, it could be possible to cache the index of tasks you care about.  These can be global variables that are set on startup and used instead of the character constants.  This eliminates the need to search whatsoever.

In addition, the timer resources involve a linear search as well, and this could easily be cached on startup (in fact the index is present in nr_of_timers in the start function).

I don't know what the performance/power consumption is without these changes, but I expect from all the calls to things like sending events and waking up tasks that this can save a significant amount of cycles.  What do you think?

-Steve

9

utFAT / Re: Detecting the presence of an SD card

« on: September 22, 2010, 04:21:23 PM »

Hi Mark,

The problem I have is that the card may very well be present, but the disk task hasn't tried to read it yet or hasn't finished mounting it yet.  In this case, I don't want to declare the SD card as missing, and load a default configuration.  I understand I can delay the initialization, but I tend to avoid relying on timing.  I want a positive confirmation that "yes, I checked and there is no SD card there."

I have added the flag to the disk flags of DISK_NOT_PRESENT, and set it in the fnInitializationError() function, and it seems to work fine.

-Steve

10

utFAT / Detecting the presence of an SD card

« on: September 21, 2010, 08:51:53 PM »

In the application I'm using, I'm trying to store the configuration of the system on the SD card.  So what I need to have happen is this:

1. system startup
2. start SD card detection.
3. if SD card is detected, read configuration, otherwise, load default configuration.

The problem with 3 is that SD card mounting is done completely asynchronously.  So far, I can't find a way to determine the difference between "No SD card detected" and "Haven't checked yet", which is pretty important for this.

I'm thinking of adding a flag to the disk flags for this, which would be set in the fnInitialisationError() function.  Something like DISK_NOT_PRESENT which would be cleared before any check is made.

Is there any flag or combination of flags that can be used equivalently?  Or another way to determine this?

-Steve

11

utFAT / Re: ensuring a directory exists and is opened

« on: September 21, 2010, 05:10:27 PM »

More updates, I'm assuming that return value is success, and it's still writing files opened with that directory to D:\ not D:\CONF.  Maybe I'm misunderstanding how this works. 

Here is some code that duplicates the problem:

Code: [Select]

static UTDIRECTORY *sdDirectory = NULL;

static int openDirectory()
{
    int result = UTFAT_SUCCESS;
    if(sdDirectory == NULL)
    {
        sdDirectory = utAllocateDirectory(DISK_D, 0);
    }
    result = utOpenDirectory("/CONF", sdDirectory);
    if(result == UTFAT_FILE_NOT_FOUND)
    {
        // need to create the directory
        result = utMakeDirectory("/CONF", sdDirectory);
        if(result == UTFAT_SUCCESS)
        {
            result = utOpenDirectory("/CONF", sdDirectory);
        }
    }
    if(result == UTFAT_PATH_IS_ROOT_REF)
        // not sure why we have to do this...
        result = UTFAT_SUCCESS;
    return result;
}

int conf_store()
{
    UTFILE newFile;
    int result = 0;
    // first, we try to store to the SD card file
    if(!openDirectory())
    {
        newFile.ptr_utDirObject = sdDirectory;
        // write the new file
        if(utOpenFile("TEST.CNF", &newFile, UTFAT_OPEN_FOR_WRITE | UTFAT_TRUNCATE | UTFAT_CREATE) == UTFAT_PATH_IS_FILE)
        {
        if((result = utWriteFile(&newFile, "hello\r\n", 7)) != UTFAT_SUCCESS)
            return result;
        }
    }
    return 0;
}

just call conf_store, and I would expect to have a D:\CONF directory with a file TEST.CNF in it.  Instead, TEST.CNF gets put into D:\

-Steve

12

utFAT / Re: ensuring a directory exists and is opened

« on: September 21, 2010, 04:16:51 PM »

I installed the new SDCard_Sim.c, the new mass_storage.[ch], and did a global search/replace of ucDirectoryFlags -> usDirectoryFlags.  I didn't want to update the other files, because I've modified them.

Now, the directory is created correctly, but my files aren't written *at all*

I'm going to do some more investigation, and see if I can narrow down my code to a small test case that you can use to reproduce, or at least see if I've done something wrong.

-Steve

[update]
OK, what I've found is, when it opens the directory, it returns UTFAT_PATH_IS_ROOT_REF instead of UTFAT_SUCCESS.  Is this valid?  My code was looking for UTFAT_SUCCESS, so it skipped trying to write any data.

There seems to be no comment to describe what this means, can you elaborate?

13

µTasker general / Re: patch for uStrcmp

« on: September 18, 2010, 09:58:04 PM »

Hi Steve

uStrcmp() is a library replacement for strcmp(). It is therefore compatible with strcmp().

According to Linux and msdn, that is incorrect.  strcmp is supposed to return <0, 0, or >0 depending on the lexicographical order:

http://msdn.microsoft.com/en-us/library/e0z9k731.aspx
http://linux.die.net/man/3/strcmp

And according to that linux man page, that implementation of strcmp is conforming to C89 and C99 standards.  So it's been like that for a while.

-Steve

14

utFAT / Re: Async operations?

« on: September 17, 2010, 07:25:26 PM »

OK,

For now I'm just resigned to use a background task that writes 512 bytes at a time, then returns.  If this proves to be too time consuming, I'll revisit this.

I'm interested in the managed reads/writes more, do you have any examples about how these are used to read/write asynchronously?  Is this code available?

-Steve

15

utFAT / Re: ensuring a directory exists and is opened

« on: September 17, 2010, 07:22:30 PM »

You can do the following:
- before opening the first directory you can invalidate the directory location using
sdDirectory->usDirectoryFlags &= ~UTDIR_VALID;
which will set you back to root. Then the check will always be for the directory "CONF" in the root directory and so it will always find it once it has once been created which will operate the way that you are expecting it to.

In fact, I did try this (I noted it before, but didn't spell it out exactly).  Here is my current code.  But it results in files being created in the root directory.  I.e. it appears that on the second openDirectory the system opens D:\ instead of D:\CONF.

Code: [Select]

static int openDirectory()
{
    int result = UTFAT_SUCCESS;
    if(sdDirectory == NULL)
    {
        sdDirectory = utAllocateDirectory(DISK_D, 0);
    }
    sdDirectory->ucDirectoryFlags &= (~UTDIR_VALID); // reset so we don't open a relative directory
    result = utOpenDirectory("/CONF", sdDirectory);
    if(result == UTFAT_FILE_NOT_FOUND)
    {
        // need to create the directory
        result = utMakeDirectory("/CONF", sdDirectory);
        if(result == UTFAT_SUCCESS)
        {
            sdDirectory->ucDirectoryFlags &= (~UTDIR_VALID);
            result = utOpenDirectory("/CONF", sdDirectory); // this seems to open D:
        }
    }
    return result;
}