Messages

1

utFAT / Re: SD Card questions

« on: February 26, 2011, 11:28:49 PM »

Hi Mark,

Thanks for the info. Yes, I was planning on having the uFileSystem look like another drive as you suggest. I just didn't know if you had plans to support the changes I need

I look forward to testing your next update.

Dave G.

2

utFAT / Re: SD Card questions

« on: February 24, 2011, 10:10:40 PM »

Hi Mark,

Thanks for the update. I would've been right there with you a year ago working on utFAT except that marketing had other ideas of what my priorities should be

When I was referring to using both utFAT and uFileSystem concurrently I was actually talking about accessing both of them through FTP.  Maybe that is possible already but I overlooked something? BTW, I don't need or want FAT on the internal filesystem.

I believe I have run across something online about a product out there that used the internal write-protect feature on an SD-CARD. In fact, I think it was a cell-phone and a microSD card. It was something that no one really uses and no one wants to use since the OS support wasn't there. I remember seeing someone have a problem with getting the card in that state and then unable to use it with Windows. In any case, that is not what I want at all. What I think is important for our customers is to support the lock/write-protect switch on the SD-Card itself which has an entirely different purpose than individually write-protecting files on the card.

LFN is important for the reason you gave -- we expect the SD Card to be used directly on a PC as well as our embedded product and to transfer data between them. I don't know yet how important it is for the product itself to create/writing LFN files. I can see how customers might think an 8.3 restriction is so "'90s" and it might shed a negative light on the product (not being up to date with technology?). However, it all depends on how we expect our customers to use the card and we haven't fleshed that out yet.

Dave G.

3

utFAT / Re: SD Card questions

« on: February 23, 2011, 04:43:06 PM »

Hi Martin,

Thanks for the info. I am not sure a serial number check would be sufficient since I see problems removing/re-inserting the same card -- it would have the same serial number. The card apparently needs to be remounted/re-initialized in this situation. This might be a simple fix without using the card present signal by keeping track of when the card responds and doesn't respond (and maybe that is what Mark was talking about but hasn't implemented?)

On page 32 of the Simplified Physical Layer Spec v3.01 under the section titled "Mechanical Write Protect Switch" it says "It is the responsibility of the host to protect the card." I don't see how that can be done without knowing the status of that mechanical switch.

Although some hardware apparently doesn't have those two signals, I think the software should support it for those who have them (which I would think is the majority of hardware designs?).

Dave G.

4

utFAT / SD Card questions

« on: February 23, 2011, 03:33:13 PM »

Hi Mark,

I now have the uTasker SD Card support working on our hardware. It works well but I found a few things lacking before we could use this in our product. I was just wondering if you have plans to implement (or have already implemented) the following features:

1) Card insertion/removal detection
2) Honor the mechanical write-protect switch on the SD card
3) Supporting both the SD Card and internal flash file system concurrently (separate drives maybe?)

For the first two items, there are signals from the SD Card socket that provide this information. Right now, I noticed things get a little wonky if I remove the SD Card and re-insert it without resetting the application. Also,  I think our customers might be upset with us if we allowed them to write to an SD Card that was supposed to be locked with the mechanical write-protect switch.

I also hope to implement a USB mass storage class to support file management on the SD Card installed on the product. I don't want to expose our customers to the debug command shell and it would be a natural to allow their host operating system to manage the files just like a USB drive.

One other thing that may be a problem is the lack of LFN support for creating/writing files. I read your document and believe I understand the reason for this limitation. I need to investigate the issue further and explain it to my team... or implement it if we feel we can support it.

Thanks,
Dave G.

5

utFAT / Re: Gnu compiler warnings in mass_storage.c

« on: February 21, 2011, 09:49:25 PM »

Hi Mark,

Yes, I do tend to maximize my warning levels   I'm sure that would explain the differences. My command line in the makefile results in the following warning settings:

-Wall -Wstrict-prototypes -Wextra -Wno-unused-parameter -Wmissing-prototypes -Wmissing-declarations

1) I thought about casting the constant to (CHAR) but I was following the pattern used in many other spots of that module.

2) I understand the desire to show initializers -- I hate seeing uninitialized variables myself. I added the -Wno-missing-field-initializers option to my command line so it is now happy with the abbreviated initializer (it was the -Wextra option that caused the warnings).

3) For the unused value warnings, I suppose we could use a pragma push/pop and a pragma to set the -Wno-unused-value option around that code. But that gets messy especially if we try to mask warnings around each statement and not the whole routine or module. The other alternative is to set a variable with the value but then that will probably generate extra code we don't need or want. So, for now, I guess I'll ignore the warnings :-/

Dave G.

6

utFAT / Gnu compiler warnings in mass_storage.c

« on: February 21, 2011, 05:45:28 PM »

Hi Mark,

I am finally getting the new code integrated into my development project and I got a warning (among many) on compiling mass_storage.c. The line I am concerned about is in fnCreateNameParagraph and looks like this:

if ((iLength == 0) && (cInputCharacter == DIR_NAME_FREE)) {

The warning that I get out of gcc v4.5.1 is: 'comparison is always false due to limited range of data type'. The compiler is warning about the comparison to DIR_NAME_FREE. If I cast the variable to a (unsigned char) the warning goes away. This cast is done all over that routine for other comparisons so I gotta wonder if cInputCharacter shouldn't be replaced with an unsigned char variable instead?

While we are on the subject of gcc warnings, the other one I have always had to "ignore" is the way static structures are initialized in the uTasker code. The initializer list always looks like = {{0}} no matter what the structure contains. The gcc compiler warns about all of these declarations because it believes the initializer list  "must agree, in type and number, with the components of the structure itself". I can get rid of the warning by removing the initializer (the standard says static structures are initialized to zero by default) or by expanding the initializer list to match the structure.

Finally, one other group of warnings I get in mass_storage.c is all the places there is a READ_SPI_DATA without storing the result. I understand the reason for this but the warning implies those lines might  not generate any code (yes, I know QDR is cast as volatile).

Of course these are just warnings and, in most cases, nothing would change in the generated code if you cleared them up. Call me a perfectionist, but I like to create warning-free code since every now and then compiler warnings actually are important to consider.

Dave G.

7

NXP^TM M522XX, KINETIS and i.MX RT / Re: iInterruptLevel problem

« on: January 10, 2011, 11:10:59 PM »

Hi Mark,

That was going to be my alternate suggestion I'll change my code to match this modification.

Thanks,
Dave G.

8

NXP^TM M522XX, KINETIS and i.MX RT / Re: iInterruptLevel problem

« on: January 10, 2011, 10:11:48 PM »

Hi Mark,

I found the problem. It turns out it is related to the use of IRQ7. The problem is the code in M5223X.c for the IRQ7 interrupt routine calls fnIRQ like all the other interrupt handlers. fnIRQ does a set and clear of iInterruptLevel around the call to the registered interrupt handler. This set/clear is a problem since IRQ7 may have interrupted while we already have interrupts disabled. When it clears iInterruptLevel and then the interrupted routine finally attempts to enable interrupts again, the "count" is off. This gets back to a question I had a long time ago of whether we should be incrementing/decrementing iInterruptLevel. I understand your logic for it being equivalent since interrupts don't normally happen when interrupts are disabled. Unfortunately, that isn't the case for IRQ7.

So, what is the proper way to fix this issue? For now, I changed fnIRQ to increment/decrement the counter but maybe we should only do that for the _irq7_handler?

Dave G.

9

NXP^TM M522XX, KINETIS and i.MX RT / Re: iInterruptLevel problem

« on: January 06, 2011, 02:47:40 PM »

Hi Mark,

Yes, I was forced to use IRQ7 for an interrupt but, based on the discussion we had back then, the only thing that interrupt service routine does now is increment a global variable and call uTaskerStateChange to activate the handler task.

I have a couple more things to try and I'll let you know what I find out. As a stop-gap measure, I'll try your idea of changing the enable routine to be more "permissive" but that is only a band-aid until I find the real problem.

Thanks,
Dave G.

10

NXP^TM M522XX, KINETIS and i.MX RT / iInterruptLevel problem

« on: January 05, 2011, 09:05:52 PM »

Hi Mark,

In our code, I added a suicide loop should we ever enter uEnable_Interrupt with iInterruptLevel equal to 0 (to catch problems like you do when compiling for the Windows simulator). This code is only compiled and used during our development cycle. We recently discovered a condition where the coldfire crashes and I can reproduce it at will now. When doing the test with development code, it ends up in the previously described suicide loop. I am not yet sure where it crashes in release code since I can't easily run the debugger on it and we have no post-mortem dump capability (yet). I am assuming at this point the crash in our release code is related to iInterruptLevel problem since the same sequence of events causes both problems.

So I went back in history to see when this problem first appeared. After trying many release versions of our code, I discovered it appears at the point I merged in the update to uTasker v1.4.2. Our previous code was based on v1.4 but I needed newer code at the time to support USB features. I have gone through a lot of diffs to check our changes against your release but have been unable to locate the problem so far. I turned off all USB code and other sections not relevant to the error condition and I can still get it to fail in code based on v1.4.2.

There were a lot of changes to uTasker between v1.4 and v1.4.2. I was wondering if you had heard of or seen this kind of problem since v1.4. Any ideas on how to track down where the mismatched interrupt enable/disable might be happening? Unfortunately, it would not be practical to try to reproduce this issue with your demo application code running. The only thought I have at this point is to squirrel away the last n return addresses on entry into both routines and look at the "trace" at the point of failure.

Any other ideas would be appreciated.

Dave G.

11

NXP^TM M522XX, KINETIS and i.MX RT / Re: Processor Utilization

« on: November 23, 2010, 04:23:04 PM »

Hi Mark,

Thanks for the suggestion. That will certainly work for what I need to determine at the moment.

There is also a desire to be able to get this type of information from the unit in the field for diagnostic purposes. I would guess I need a gated hardware timer to measure the time in one mode and average it over some period.

12

NXP^TM M522XX, KINETIS and i.MX RT / Processor Utilization

« on: November 22, 2010, 03:26:22 PM »

I was wondering if anyone has added any code to uTasker to measure processor utilization on the Coldfire. Before adding yet another big chunk of code to our application, I am concerned it may be running out of horsepower on the Coldfire. I guess one way to measure it is to see how much time is spent (using a hardware timer?) in the scheduler waiting for a task to run.

13

NXP^TM M522XX, KINETIS and i.MX RT / Re: USB Sleep and Resume interrupts

« on: July 15, 2010, 01:46:13 PM »

Hi Mark,

So the issue of multiple suspends without a resume is possible and presumably only caused by the noise issue with the motor cable. It didn't make a difference when I tried clearing just the one interrupt state.

Our hardware guys say the interface design already implemented your suggestions except the ferrite beads. They will be testing that in the future.

I guess the only other thing we can say is that there is no practical way to recover from a suspend caused by noise other than a cable pull or having the host simulate a cable pull with a reset.

Thanks,
Dave G.

14

NXP^TM M522XX, KINETIS and i.MX RT / Re: USB Sleep and Resume interrupts

« on: July 14, 2010, 04:12:24 PM »

Hi Mark,

Based on our USB event counters (and debug messages), we are definitely getting multiple suspend interrupts without a resume interrupt. In one test (before the motor encoder cable was grounded properly) our counters showed over 700 suspends with 0 resumes. I know the resume counter works because I have seen it count on normal resume states.

I don't see in the code where you are disabling the Sleep interrupt. You do enable/disable the Resume interrupt. Here is the snippet I have in USB_DRV.c:

Code: [Select]

           if (ucUSB_Int_status & SLEEP) {                              // suspend state detected - 3ms of idle USB bus detected (low speed D+ = 0, D- = 1 / high speed D+ = 1, D- = 0)
                INT_STAT = (SLEEP | RESUME);                             // reset flag
                INT_ENB |= RESUME_EN;                                    // enable resume interrupt
                fnUSB_handle_frame(USB_SUSPEND_DETECTED, 0, 0, 0);       // generic handler routine
            }
            if (ucUSB_Int_status & RESUME) {                             // resume detected - 10ms inverted idle USB bus state (low speed D+ = 1, D- = 0 / high speed D+ = 0, D- = 1)
            INT_STAT = (SLEEP | RESUME);                             // reset flag
                INT_ENB &= ~RESUME_EN;                                   // disable resume interrupt
                fnUSB_handle_frame(USB_RESUME_DETECTED, 0, 0, 0);        // generic handler routine
            }

I also hope it is a hardware issue

Dave G.

15

NXP^TM M522XX, KINETIS and i.MX RT / Re: USB Sleep and Resume interrupts

« on: July 14, 2010, 03:00:28 PM »

Mark,

I am a little confused about this. If the device is waiting for an "inverted idle period" wouldn't that be happening because it will eventually see a start of frame every 1mSec coming from the host again? Or does the device need to see a resume state packet sent from the host?

How is it the device can be entering a sleep state multiple times without first resuming?

Our hardware guys are looking at the interface circuit to see if there is an error that is causing the noise sensitivity.

Dave G.