Topics

1

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.

2

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.

3

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.

4

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.

5

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

« on: July 13, 2010, 05:12:05 PM »

Hi Mark,

We have a problem where we are getting repeated USB Suspends with no intervening USB Resumes.

Looking at the code in the ISR, I see the Sleep interrupt clears both the Sleep and Resume interrupt bits. I am wondering if the reason we are not seeing the Resume is that the resume state was asserted between the time the interrupt status was captured at the beginning of the ISR and the point where it is cleared by the code for the Sleep interrupt.

Why do you clear both bits in the Sleep interrupt code (and the Resume interrupt code for that matter).

Thanks,
Dave G.

6

µTasker general / USB buffering problem?

« on: March 23, 2010, 09:14:00 PM »

Hi Mark,

I am working on implementing a USB slave device for our uTasker-based product. I have defined 2 bulk endpoints with 320 byte queues. Our normal message size is approx 240-253 bytes. If the message size is below the max packet size of the full-speed endpoint (64 bytes) everything works great. The problem starts when we use larger messages. It seems the accounting of how many bytes are left to transmit back to the host is getting messed up. We get communications working for a while (20-30 seconds). But, at some point, uTasker starts belching out huge amount of bad data like there was a wrap-around of the bytes left, We monitor the USB traffic using USBlyzer (great tool worth the money). Even before this fatal situation, the packets coming back to the host don't seem to be what I would expect -- I think I should expect packets of 64 bytes until the last one but, instead, we end up getting random packet sizes until the message is complete.

I know the uTasker demo program implements a CDC class device (UART) and I am guessing that code never uses large messages. I guess it is possible this situation has never been tested? I haven't been able to place a breakpoint at the point of failure. I am slowly learning the uTasker USB driver code and was wondering if you might have some advice on what to look for.

Thanks,
Dave G.

7

NXP^TM M522XX, KINETIS and i.MX RT / Coldfire RTC Init Code

« on: December 14, 2009, 10:23:03 PM »

Hi Mark,

We discovered a timing issue with when the RTC is initialize during power-up.

But first, I wanted to ask about the two writes to MCF_CLOCK_RTCCR. The reference manual shows an example where the difference between the two writes is that the first one does not include the RTCSEL_OSC bit. I was wondering why your init code has identical values for both writes to MCF_CLOCK_RTCCR. If there is a reason I would also like to know why then the register needs to be written to twice.

Now, on to the timing problem we have. Our board design uses a super-cap as the power source for Vstby. If the super-cap discharges below 1.8 volts, we lose the RTC and battery-backed SRAM as expected. Unfortunately, it take significant time to recharge the super-cap when power is applied to the board (up to 750mSecs). While the voltage is still below the 1.8v threshold, the init code for the RTC does nothing and that, unfortunately, is run well before the RTC is viable. So I figured I would create a task that is delayed a couple seconds after power-up which would just have those few instructions to initialize the RTC. Do you see any problem with that? Do you see a better solution for our situation?

Thanks,
Dave G.

8

µTasker general / Username and/or Password on Telnet?

« on: November 24, 2009, 04:15:17 PM »

I was looking through the code to see where I might add code to require a username and password on the telnet session. I see a function called fnInitiateLogin that might be the best location for this. I also see a check on the return of this function for a value called DO_PASSWORD_ENTRY. However, it is never set.  I was wondering if anyone had already written code to protect the system. I actually would like password protection for both telnet and serial port access to the debug/maintenance menus.

Thanks,
Dave G.

9

µTasker general / Processor Utilization

« on: November 23, 2009, 04:45:34 PM »

Hi Mark,

Have you thought at all on how to measure processor utilization with uTasker? Basically, it would be really useful to know what percent of time is spent waiting for tasks to run.

Dave G.

10

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

« on: November 18, 2009, 03:06:17 PM »

I added a new interrupt to our application (using IRQ7 and the demo code for port interrupts) and can now get into a state where the tick interrupt is no longer happening. Looking into the problem I noticed that iInterruptLevel seems to be used as a nesting counter in the uDisable_Interrupt and uEnable_Interrupt routines. However, I also see almost everywhere else it is being set directly to 0 or 1 as if it was some kind of flag.

So I wondered what the value of this variable was while we are in the condition where we lost our system tick. Sure enough it is set to -1 which I don't think should ever happen. I believe this might be happening if the interrupts got nested and one routine sets it to zero on exit and the other routine calls uEnable_Interrupt which decrements before enabling the interrupts. But when it decremented to -1 it did not enable the interrupt as it should have.

So is iInterruptLevel a nesting counter or a flag? If it really is meant to be a counter shouldn't all 78 places in M5223X.c be doing increments and decrements instead of setting it to 0 and 1? I see the code for the CAN interrupt is doing that but very few if any other routines do it.

Dave G.

11

NXP^TM M522XX, KINETIS and i.MX RT / Calculation of BWT WMR value

« on: October 14, 2009, 11:18:52 PM »

Hi Mark,

I am looking at the calculation for the value to place in the WMR register for the backup watchdog timer on a 5225x. This calculation is done in a #define for BWT_TIMEOUT_SYS_CLK in M5223x.h.

I am trying to figure out where the division of the BUS_CLOCK by 2 is coming from. The equation in the reference manual to come up with the timeout period is

T = [(WM + 1) ? 4096 + 4]?
where T is the timeout period and ? is the period of the BWT’s input clock.

When I plugged in the value actually being set in the WMR (19530) the result was approx. 1 second (with the belief that BUS_CLOCK is 80MHz). However, the intent is (and the comments indicate) that we wanted a 2 second timeout. So I did a little algebra against the documented equation and I don't get the division by 2 that your code has in it.

Where am I going wrong with the math?

12

µTasker general / fnRandom() not changing in v1.4

« on: September 29, 2009, 08:26:55 PM »

Hi Mark,

I saw back in April someone found that fnRandom() was not changing. You found a bug in the function and found a replacement algorithm (see: http://www.utasker.com/forum/index.php?topic=582.0).

In my copy of v1.4 there is a line missing in fnRandom which is critical to successfully generating random numbers. After calculating the new value in ulShifter, we need a line to store it back into ulRandomNumber:

Code: [Select]

usRandomNumber = usShifter;
Otherwise ulShifter will be calculated to be the same everytime the function is called.

Dave G.

13

NXP^TM M522XX, KINETIS and i.MX RT / Configuration for MCF52258

« on: September 22, 2009, 01:47:02 PM »

I am implementing uTasker on a board that has a 52258. The one difference between the 52259 and 52258 is that my chip doesn't have the random number generator. The problem is, I don't see how to use the definitions in config.h to tell uTasker that I do not have the RNG while at the same time using all the other code for the 5225x.

IOW, defining _M5225X will bring in the RNG code which just hangs forever on my chip. For now, I am commenting out the definition of RND_HW_SUPPORT in M5223X.h to get around the issue.

I just thought you should know that not all 5225x chips will work when configuring for _M5225X. In fact, only two of the six chips in the 5225x family will work.

Dave G.

14

NXP^TM M522XX, KINETIS and i.MX RT / Bootloader code & GNU Toolchain

« on: September 08, 2009, 08:41:13 PM »

These may be noobie questions but I am working on a 52259 implementation and trying to get the bootloader functional. I switched to v1.4 when it came out and I am using the GNU toolchain.

The first thing I see is that after the following comment line in /Applications/uTaskerBoot/uTaskerBootLoader.c there doesn't appear to be any code for the _M5223X configuration.

   // The boot loader has detected the uTasker application code so it will be started now

I would expect to see a line like

   start_application(UTASKER_APP_START);                                // jump to the application

So I put that line in.  

But then I looked at the code for the function start_application defined in mcf5223X_GNU_boot.s. This short assembler routine does not appear to be getting an argument off the stack but instead gets it from register D0. The code generated by the compiler for the call to start_application did a PEA 0x1000 before the subroutine jump so I think I would expect the routine to get the arg off the stack with something like 'move.l  4(%SP),%A0'.

Am I all wet with these questions? Has the bootloader been tested with the Coldfire processors? Is this something caused by using the GNU toolchain instead of CW? But I still don't see how any code is generated in the uTaskerBoot function to make the call to an existing application when _M5223X is defined.

Thanks for any help.

Dave G.

15

µTasker general / Source for small utilities

« on: June 24, 2009, 04:29:00 PM »

Is there source available for the two utilities used for creating/manipulating binary files?

I am talking about uTaskterConvert and uTaskerCombine.

Thanks,
Dave G.