Messages

31

NXP^TM M522XX, KINETIS and i.MX RT / Re: Service Pack 6 and CodeWarrior 7.0

« on: March 01, 2008, 07:35:06 AM »

Hi, Mark.

Sorry to have been silent for the last couple of days, but other projects intruded.

I've now got SP6 and CW 7.0 working together as expected -- but I can't be sure what it is that I did that made this happen.  My best guess is that wiping out the data directory, ...\Applications\uTaskerV1.3\CodeWarrior_M5223X\uTaskerV1.3\uTaskerV1.3_Data, and then restarting CW 7.0 may have been what did the trick.  But I also spent a bit of time with a new project, staring at its startup code, trying to decide whether I needed to prepend an underscore to the start label in Startup.s; i.e., trying to decide if start or _start was the right value for the Entry point in the linker options (I decided it should be start).  Maybe my manipulation of the linker options reset something.  As you might be able to tell, I'm grasping at straws and don't know what fixed the problem.

Now, when the debugger starts, it shows .debug_frame +0x00000005 and DummyFn1.  I can single step as expected, and if I let the program run and then stop it using "break", it ends up in a reasonable place in the program, not still stuck at the top.

I don't yet have the code I wrote working as it did with SP5 and CW6.4, but now I can work on that problem.

Best regards,
    Richard

32

NXP^TM M522XX, KINETIS and i.MX RT / Re: Service Pack 6 and CodeWarrior 7.0

« on: February 27, 2008, 08:03:09 AM »

Hi, Mark.

I have set WATCHDOG_DISABLED to (1), commented out M52235EVB, and defined M52233DEMO.

By step 1, I assume you mean to open the settings panel (Alt+F7) and set the debugger setting "Stop on application launch" to "User specified" and set that to "main".
I then do steps 2-4.
However, quitting and restarting the debugger doesn't get anywhere.  The red ball at 0x08 shows up as hollow.  Using the cursor and right clicking, I can enable the breakpoint.  The arrow showing the PC is at 0x00, and anything done to try to start the computer does almost nothing.  If I press F11 sometimes I can see the red square ("break") flash for an instant, but the big blue arrow (which I presume represents the contents of the program counter) remains at 00000000.  If I click the run icon, the debugger reports that it is executing, but then pressing the break icon shows that the PC is still at 0x00.

One more thing.  If I create a totally new project using CW 7.0, it starts at _startup and happily steps through its initial instructions.

Weird!

    - Richard

33

NXP^TM M522XX, KINETIS and i.MX RT / Re: Service Pack 6 and CodeWarrior 7.0

« on: February 27, 2008, 12:30:04 AM »

Hi, Mark.

I'm really puzzled.  I've tried everything I can think of, including downloading and installing a new version of CW 7.0.  I did this even though it was identical to the version I had already installed, just in case the installation program set some registry values or performed some other magic.  I also used a new M52233DEMO board.  As I said, I can successfully compile the code and erase and program the M52233 = the first 5 steps of your test.  But when I run the debugger, it opens pointing at .debug_frame + 0x00000000, and nothing I can do will convince it to take even one step into the program.  It's as though I have the wrong debugger or maybe the wrong linker.  Or maybe some parameter file or initialization values are missing and the linker or debugger is defaulting to some bizarre values.

Here is what the debugger is pointing at:

Code: [Select]

00000000: 2000            move.l   d0,d0
00000002: 8000            or.b     d0,d0
00000004: 00000008        ori.b    #0x8,d0
00000008: 46FC2700        move     #9984,sr
0000000C: 203C20000000    move.l   #536870912,d0
00000012: 068000000021    addi.l   #33,d0
00000018: 4E7B0C05        movec    d0,rambar1
0000001C: 2E7C20008000    movea.l  #536903680,a7
00000022: 203C40000000    move.l   #1073741824,d0
00000028: 068000000001    addi.l   #1,d0
0000002E: 23C040000000    move.l   d0,0x40000000 (0x40000000)
00000034: 203C00000161    move.l   #353,d0
0000003A: 4E7B0C04        movec    d0,rambar
0000003E: 4EB9000027BC    jsr      mcf52235_init (0x27bc)  ; 0x000027bc
00000044: 4EB900000420    jsr      main (0x420)            ; 0x00000420
0000004A: 4E7B0801        movec    d0,vbr
0000004E: 4E71            nop
00000050: 4E75            rts

By looking at startup.s, I see that it should be pointing at location 0x8 instead of 0x0.  If I try to set the program counter to that value, I get debugger error 104101 that says "Could not get information on program counter register by name or generic ID.  An error occurred while trying to write the register value."

Does this error when trying to change the program counter help in assessing possible problems?

I am now stuck.  I don't even know what else to try.  If I reach for straws, I wonder if it is possible that I have a file on my machine that interferes with the normal operation of CW 7.0 (but not CW 6.4, where I don't have these problems) or that I lack a crucial file that is on your machine.

Any thoughts?

Thanks,
    Richard

34

NXP^TM M522XX, KINETIS and i.MX RT / Service Pack 6 and CodeWarrior 7.0

« on: February 25, 2008, 03:09:49 AM »

Hi.

Has anyone succeeded in getting Service Pack 6 to run using CodeWarrior 7.0?

A couple of months ago, Freescale upgraded CodeWarrior to version 7.0 (see <http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=CWS-MCF-STDED-CX&fsrch=1>).  As is now usual, the "standard edition" is free, so I downloaded it and have been using it for my project, which is based on Mark's V1.3 SP5 code and its various patches.  It runs on the M52233DEMO board.

To remain current, I decided to switch my project over to SP6 and then ran into trouble.  To try to figure out what went wrong, I went back to the original V1.3 release, loaded SP6 over it, renamed its config_ref... to config.h and made two copies of the resultant directory structure.

I ran one copy using CW 6.4, using CFM_MCXF52233 to set the parameters of the Flash Programmer.  This appears to have been successful, because the program runs, and if I set a breakpoint at the beginning of fnApplication(), it gets to that breakpoint and halts.

I tried then to run the other copy using CW 7.0, using MCF_52233_INTFLASH.xml to set the parameters of the Flash Programmer.  This version can erase the FLASH and load the program.  However, when I start the debugger, it opens at .debug_frame + 0x00000000, and nothing I can do will convince it to take even one step into the program.  Single stepping does nothing.  If I start it running and then stop it, it's always at the first step.  If I set a breakpoint at the beginning of fnApplication(), it never gets there.

It must be possible to make SP6 run using CW 7.0.  Is there some magic I've missed?

Thanks,
    Richard

35

NXP^TM M522XX, KINETIS and i.MX RT / Re: Web parameters

« on: December 02, 2007, 08:56:34 AM »

Hi, Mark.

Thanks for your prior reply; it was a big help.

I am finally working on displaying data to a web page.  I have figured out the various levels of indirection that ultimately invoke fnInsertString(ptrBuffer, usTxLength, usLengthToSend).  As written, in fnInsertString(), the value of usTxLength is used only to see if it's zero or not, to decide whether the function was called as a result of £v or £H.

I have a situation where I have several identical objects of a couple of different types to monitor, with a couple of different kinds of values, so I'd like to have the HTML embed the ID of the object and its parameter following the £ that indicates a field to be replaced with data.  I understand that I could use £HXY for this, but I'd like to have additional possibilities, not just H.  I'd like to use £JXY to display the Y parameter of the object number X of type 1 and £KXY to display the Y parameter of the object number X of type 2, etc.

My suggestion is this: why not change usTxLength to usFieldCode, where the various field codes are
    v - for value (i.e., as currently used)
    H - for dynamic content (the current stub)
and then any other codes I care to insert that are not already used.

I could simply add

Code: [Select]


    #define WEB_INSERT_OBJECT1        'J'
    #define WEB_INSERT_OBJECT2        'K'
    // etc.
to config.h just after the definition of WEB_PARSER_START.

This collapses the two calls to fnInsertValue() that invoke fnInsertString() in fnWebParGenerator() to one, giving

Code: [Select]

unsigned short  usFieldCode; // character following £ identifies type of field, e.g., v for value
// ...
usFieldCode = (unsigned short)*ptrBuffer++;

switch (usFieldCode) {     // check which of our fields this is
  // ...
  case WEB_INSERT_STRING:  // to insert value string field
  case WEB_INSERT_DYNAMIC: // to insert dynamic HTML
  case WEB_INSERT_OBJECT1: // insert string for objects of type 1
  case WEB_INSERT_OBJECT2: // insert string for objects of type 2
  // etc.         
    if (fnInsertValue) {
        cInsertString = fnInsertValue(ptrBuffer, usFieldCode, &usInsertLength); // allow application to insert its own string
    }
    break;

and the test near the top of fnInsertString() is based on the code of the field, usFieldCode, rather than whether usTxLength is zero.

I've programmed this, and it appears to work.

What I don't know -- and this is the reason for this lengthy query -- is whether it's necessary to worry about the length of the resultant string.  I'd even be willing to guarantee that it remains shorter than MAX_SIMPLE_INSERT.  Specifically, will fnWebParGenerator() handle the possibility that the result will not fit in the space available in the current TCP frame?  I note that in the case of £vXY, this must already be the case.  Put another way, why was the value usTxLength passed in to the function fnInsertString() beyond acting as a flag for one of two behaviors?

Thanks,
    Richard

P.S. in the various places where the code returns cNoEntry, the length is set using *usLengthToSend = sizeof(cNoEntry) - 1;.  This has the effect of chopping off the final '-' from the message.

36

µTasker general / Re: Working with tasks

« on: November 13, 2007, 06:33:04 AM »

I've had mixed success defining tasks.  The one that has defeated me is an initialization task that I want to run once, as the system starts, and never again.  Starting from the demo tutorial code, I've included something like the following in TaskConfig.h:

Code: [Select]

  #define TASK_GINIT      'g'         // g initialization

  extern void fnGinit(TTASKTABLE *);

  const UTASK_TASK ctNodes[] = {        // we use a single fixed configuration (single node)
    DEFAULT_NODE_NUMBER,                // configuration our single node
  //...
    TASK_GINIT,                         // g initialization
  //...

  const UTASKTABLEINIT ctTaskTable[] = {
  //...
  { "gInitialize", fnGinit, NO_QUE, 0, 0, UTASKER_ACTIVATE }, // gInitialization
  //...

and in Gfiles.c, is something like
 

Code: [Select]

  void fnGinit(TTASKTABLE *ptrTaskTable)
  {
      unsigned int i;

      for (i = 0; i < WHATEVER; i++) {
          //...
      }
  }

The result is that the system works for a short while, going through fnGinit and another task I've created that runs every second.  After two or three seconds, the processor is restarted by the watchdog!

If I simply comment out the line
{ "gInitialize", fnGinit, NO_QUE, 0, 0, UTASKER_ACTIVATE }, // gInitialization
the problem goes away.

If I leave the line in and change UTASKER_ACTIVATE to UTASKER_STOP, the problem remains, despite the fact that the process will not run in the UTASKER_STOP state.  Thus, nothing the process might do can account for the problem.

This leads me to believe that it is the line in the ctTaskTable that causes the problem, but I can't begin to imagine why.

Any comments appreciated!  Thanks,
Richard

37

µTasker general / Accessing registers without pointers

« on: October 26, 2007, 01:59:21 AM »

CONTEXT:
The Freescale Application Note AN2616, "Getting Started with HCS08 and CodeWarrior Using C", section 6.6, recommends defining a register via a structure, as in this example:

Code: [Select]

/*** DBGC - Debug Control Register ***/
typedef union {
  byte Byte;
  struct {
    byte RWBEN :1; /* Enable R/W for Comparator B */
    byte RWB :1; /* R/W Comparison Value for Comparator B */
    byte RWAEN :1; /* Enable R/W for Comparator A */
    byte RWA :1; /* R/W Comparison Value for Comparator A */
    byte BRKEN :1; /* Break Enable */
    byte TAG :1; /* Tag/Force Select */
    byte ARM :1; /* Arm Control */
    byte DBGEN :1; /* Debug Module Enable */
  } Bits;
} DBGCSTR;
extern volatile DBGCSTR _DBGC @0x00001816;
using these data types:

Code: [Select]

/* Types definition */
typedef unsigned char byte;
typedef unsigned int word;
typedef unsigned long dword;
typedef unsigned long dlong[2];

To access the bits of DBGC, you can write things like

Code: [Select]

DBGC.Bits.RWB = 1; /*Set RWB bit of DBGC */
DBGC.Bits.RWB = 0; /*Clear RWB bit of DBGC */
Note that this avoids the use of a pointer to access DBGC by telling the compiler where it is located.

PROBLEM:
This may work fine for the CodeWarrior HCS08 compiler but not for either the CodeWarrior Coldfire or the Microsoft Visual Studio 2005 compiler.  Both are unhappy about dealing with a statement like
  extern volatile DBGCSTR _DBGC @0x00001816;
which is supposed to declare that DBGC is at location 0x00001816.

QUESTION:
How can I achieve the same effect with the CodeWarrior and the Microsoft Visual Studio compilers?  I.e., how can I tell these compilers what address to assign to a variable?

Thanks,
    Richard

38

NXP^TM M522XX, KINETIS and i.MX RT / Re: error C2099: initializer is not a constant

« on: October 06, 2007, 05:26:47 AM »

Thanks.  What I've decided to do is use my hand-calculated value in the case of the Microsoft compiler and then check it using the _ASSERT macro.  It's clumsy, but it guarantees that if the value of a or b is changed, then c must be changed correspondingly.  The resultant code is below.  Note the inclusion of <crtdbg.h>.

Code: [Select]

const int a=1;
const int b=2;

#ifdef _WINDOWS
    const int c=3;
#else
    const int c=a+b;
#endif

#ifdef _WINDOWS
    #include <crtdbg.h>
#endif


void main(){
#ifdef _WINDOWS
    _ASSERT(c == (a+b));
#endif
}


39

NXP^TM M522XX, KINETIS and i.MX RT / error C2099: initializer is not a constant

« on: October 05, 2007, 05:49:10 AM »

The following C code

Code: [Select]

const int a=1;
const int b=2;
const int c=a+b;
void main(){}
generates an "error C2099: initializer is not a constant" for the line const int c=a+b; when compiled with Visual C++ 2005 Express Edition (the compiler I use for simulation) but not when compiled with the Freescale CodeWarrior C compiler.
   Is this a bug of the Visual C++ compiler or a non-standard extension of the Freescale compiler?
   I know I could use various #define work arounds, but would prefer not to, for exactly the reasons that const was added to C.  Is there a good way around this?
    Thanks,
        Richly

40

NXP^TM M522XX, KINETIS and i.MX RT / Web parameters

« on: September 26, 2007, 06:21:19 AM »

Hi. Do you have a write up of the web parameter facility of your demo software, i.e., the part of the web server that deals with "£" embedded in the html pages it serves?
Thanks,
    Richard

41

NXP^TM M522XX, KINETIS and i.MX RT / Re: Present Time

« on: September 03, 2007, 12:14:06 AM »

I just tested and didn't need to set the LCD define to get the time to be displayed correcty.
I wonder whether the Time Server didn't respond when you did the test the first time (sometimes this happens but on the second attempt it is OK).

Hmmm...I thought I tried it more than once, but I'll try it again in a week when I get back from this trip.

The time server delivers the number of elapsed seconds since a certain point in time (I think the first second of 1900).
    #define REL_9_1_2007           (unsigned long)0xc94d4b7b

On this day (9.1.2007) I simply ran the demo and looked at the number of seconds the server gave back.

I noticed the date, but forgot that it wasn't being written in the nutty US way; i.e., I interpreted it as 1 September 2007 rather than 9 January 2007. It doesn't really matter in this case, though I did briefly wonder why you'd chosen a date in the future and what would happen on 1 September. [Aside - totally irrelevant to this, but maybe an interesting anecdote: It did, once, make a mess of a graphing program that was using the Windows system time as the x-axis. A customer in Quebec had a machine that was originally configured for French and then back to English, and the internally reported time, as used in the program, calculated that the difference between 23:59 on 3.5 to 00:00 on 3.6 was a month rather than a minute, stretching the graph accordingly.  It was quite the mystery until the 13th of the month, when we were told that the date was illegal.]

Your correction to your local time is correct - although a neat way to do it would be to add the correction (from GMT) into the user parameter block so that this can be a user configuration (rather than define)...
By using Browser time zone information it could possibly be displayed automatically corrected on the administrator page!

Yes, but I'm too new at using this system to have figured out how to use the user parameter block already.

... But this would allow the day, date to be extracted from the the Time Server seconds value, the RTC set be set and then full calendar support would be available for applications - the only thing that is not automatic is the summer/winter time shift but this if generally the case for and realisation; it is usually up to the user to adjust it accordingly.

I'm looking forward to this; but for my purposes right now, local time (or even UT) accurate to the minute is probably good enough.

Best regards,
    Richard

42

NXP^TM M522XX, KINETIS and i.MX RT / Present Time

« on: September 01, 2007, 03:40:44 AM »

The "Present Time" box of the "µTasker - administration" side web page <.../5admin.htm> doesn't display the current time unless both USE_TIME_SERVER and SUPPORT_LCD constants have been defined.  You need SUPPORT_LCD even if you don't have an LCD attached.

The time shown (in the summer) is the time in London, not UT (a.k.a. GMT).  In the winter, I guess the time shown would be the time in Switzerland.  In any case, to set the time to Eastern Daylight Time (my local time, five hours behind London), I've added two lines to application.c:
       #define TIMEZONE (-5*60*60)
near where REL_9_1_2007 is defined (though it should probably be in config.h) and added
        ulPresentTime += TIMEZONE;
just after the line
        ulPresentTime -= REL_9_1_2007;                                   // relative to 0:0:0 on 9.1.2007

Best regards,
    Richard

43

NXP^TM M522XX, KINETIS and i.MX RT / Re: Exception Vector Name: Address Error

« on: August 31, 2007, 12:01:06 AM »

You wrote CW1.3 but I am assuming you meant to write CW6.3.

You're right, 6.3 (I was focusing on the 3, since I've recently downloaded but not installed 6.4).

1. Ensure that you are building the project "M5223XEVB_ROM" and not the "bare_min_app_rom" since this will only work together with the boot loader project.

OH! Again, you're right! I had the wrong project -- didn't realize there was more than one.

Thanks.  That solves the problem.

    - Richard

44

NXP^TM M522XX, KINETIS and i.MX RT / Exception Vector Name: Address Error

« on: August 30, 2007, 09:01:07 PM »

Having gone through the simulated Demo board portion of the tutorial, I'm now starting with the actual Demo board version of the tutorial, using version 1.3 of Freescale's CodeWarrior.  I've used this software extensively with the Freescale WebServer example, but I can't get it to work with the uTasker example. I can erase and program and verify the chip on the Demo board, but as soon as I try to run the program, I get an error that reads "Exception Vector Name: Address Error".  There is a reference to DummyFn1, which shows up in the Maps but nowhere in the code.  I'm not sure it's the source of the error. In any case, I have no idea how to proceed from here and would appreciate whatever help you can give.
Thanks.