Topics

1

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

2

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

3

µ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

4

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

5

utFAT / ensuring a directory exists and is opened

« on: September 16, 2010, 07:55:43 PM »

I'm having trouble ensuring that a directory is present and opened.  Here is the code I have:

Code: [Select]

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);
        }
    }
    return result;
}
The first time this function is called, the directory D:\CONF is created and opened
Upon the second time calling this, the directory D:\CONF\CONF is created, but D:\CONF is opened.

I tried adding a statement before opening the directory to clear the VALID bit, but what that results in is the directory D:\CONF being created, but D:\ being opened.

I'm unsure how the directory argument to utOpenDirectory is used, I thought it was just a place to put the opened directory, but it appears to play a role in the relation of the directory to open.  Plus, makeDirectory doesn't have any docs, so I'm not sure how it's used there either.

What I want is for this function to work even if someone has removed the directory between calls.

-Steve

6

utFAT / Async operations?

« on: September 15, 2010, 07:01:39 PM »

Hi,

Are there any plans to make async operations possible on the utFAT/SD system?  In an application I'm writing, the config and logs will be stored on the SD card, but I'm concerned that the writing of the log/config will consume too many cycles, since the write is synchronous.  I understand the module is preliminary, but so far, it's worked for me!

-Steve

7

µTasker general / patch for uStrcmp

« on: September 14, 2010, 01:57:49 PM »

While building a binary search on strings, I found that uStrcmp was inadequate.  It only tests equality, where I need it to test order as well.

Here is a patch if anyone is interested, it should be just as fast as the original, since the test for order doesn't occur until a difference is found.

-Steve